From common-issues-return-147815-archive-asf-public=cust-asf.ponee.io@hadoop.apache.org Sun Feb 11 11:05:05 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id E195018064E for ; Sun, 11 Feb 2018 11:05:05 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id D15F2160C4E; Sun, 11 Feb 2018 10:05:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 238B5160C36 for ; Sun, 11 Feb 2018 11:05:04 +0100 (CET) Received: (qmail 67612 invoked by uid 500); 11 Feb 2018 10:05:04 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 67601 invoked by uid 99); 11 Feb 2018 10:05:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Feb 2018 10:05:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8C81A1A0A44 for ; Sun, 11 Feb 2018 10:05:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 3LL-csN91Rgv for ; Sun, 11 Feb 2018 10:05:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 05C2E5F181 for ; Sun, 11 Feb 2018 10:05:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 39D0FE00B5 for ; Sun, 11 Feb 2018 10:05:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id EADEB21E83 for ; Sun, 11 Feb 2018 10:05:00 +0000 (UTC) Date: Sun, 11 Feb 2018 10:05:00 +0000 (UTC) From: "Elek, Marton (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-15007) Stabilize and document Configuration element MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HADOOP-15007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16359873#comment-16359873 ] Elek, Marton commented on HADOOP-15007: --------------------------------------- Thanks [~ajayydv] the patch. But (to be honest) this is not exactly what I proposed. From my previous comment: {quote}My preference is: # Don't use tags in the code at all (only return existing tags as a List to the ui) # Use enums to represent tags # Use string constants to represent tags I agree with Anu that 2 is better then 3 and I agree we Steve that 1 is better then 2. {quote} It could my fault as my proposal was not clean enough, but the current patch implements the 3rd option. I agreed with [~anu] that enum is better than string constant. My proposal was to remove the PropertyTag class at all as none of the fields are used. The only used code from PropertyTag is the contains method. But as the _contains_ method is used to log something on the *trace* level (I am pretty sure that it almost never never be logged in the universe) I proposed to remove the PropertyTag class and the check and Configuration.java:3113 (That is 1st option on my list). To avoid typo I proposed to extend TestConfigurationFieldsBase (in different jira) to do a similar check based on the existing used tags (eg. every tag should be associated at least 4 config keys) I don't say this is the best approach, but it was my original proposal. > Stabilize and document Configuration element > -------------------------------------------------- > > Key: HADOOP-15007 > URL: https://issues.apache.org/jira/browse/HADOOP-15007 > Project: Hadoop Common > Issue Type: Improvement > Components: conf > Affects Versions: 3.1.0 > Reporter: Steve Loughran > Assignee: Ajay Kumar > Priority: Blocker > Attachments: HADOOP-15007.000.patch > > > HDFS-12350 (moved to HADOOP-15005). Adds the ability to tag properties with a value. > We need to make sure that this feature is backwards compatible & usable in production. That's docs, testing, marshalling etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: common-issues-help@hadoop.apache.org