[ https://issues.apache.org/jira/browse/HADOOP-15694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608273#comment-16608273 ]
Thomas Marquardt commented on HADOOP-15694: ------------------------------------------- # *AbfsConfiguration.java@L212*: getBoolean returns the account-agnostic value if both the account-agnostic and account-specific properties are set. We want it to return account-specific in this case. Same is true for getLong. # Can we add test cases for these new methods on AbfsConfiguration to validate 1 above? # I know it's late for this comment, but I realized while reviewing this that it is a feature which would be nice in hadoop-common. This change effectively introduces a collection for configuration property keys, where an optional default is overridden by a named subkey. It could be added to the Configuration system without breaking existing config. I mean, you could have XML like below, and look up values for the sub key by passing the string "\{KEY}.\{SUBKEY}" to Configuration.get(). You can disallow '.' in the \{SUBKEY} and fallback to the \{DEFAULT_VALUE} if \{SUBKEY} does not exist in the collection. See XML below: {code:java} <property> <name>{KEY}</name> <value>{DEFAULT_VALUE}</value> <subKeyCollection> <add name="{SUBKEY1}" value="{VALUE1}"/> <add name="{SUBKEY2}" value="{VALUE2}"/> <!-- ... --> <add name="{SUBKEYN}" value="{VALUEN}"/> </subKeyCollection> </property> {code} > ABFS: Allow OAuth credentials to not be tied to accounts > -------------------------------------------------------- > > Key: HADOOP-15694 > URL: https://issues.apache.org/jira/browse/HADOOP-15694 > Project: Hadoop Common > Issue Type: Sub-task > Reporter: Sean Mackrory > Assignee: Sean Mackrory > Priority: Major > Attachments: HADOOP-15694-HADOOP-15407-005.patch, > HADOOP-15694-HADOOP-15407.003.patch, HADOOP-15694-HADOOP-15407.004.patch, > HADOOP-15694-HADOOP-15407.006.patch, HADOOP-15694.001.patch, > HADOOP-15694.002.patch, HADOOP-15694.003.patch > > > Now that there's OAuth support, it's possible to have a notion of identity > that's distinct from the account itself. If a cluster is configured via OAuth > with it's own identity, it's likely operators will want to use that identity > regardless of which storage account a job uses. > So OAuth configs right now (and probably others) are looked up with > <config_key>.<account>. I propose that we add a function for looking up these > configs that returns an account-specific value if it exists, but in the event > it does not will also try to return <config_key>, if that exists. > I can work on a patch for this if nobody has any objections. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org