config: deprecated settings don't override later non deprecated names

I'm not sure how the library is supposed to pick between the two names. If it encounters both a deprecated name and a "new" name, the "new" name seems like the obvious choice for what should be used. I don't think we want the deprecated name used unless the "new" name is not present in the configuration file.

Doug: the behavior you are suggesting makes sense, but it is the opposite of the behavior described in this bug report (in which the deprecated sql_connection name is taking precedence). From your comment, it sounds like you actually believe the behavior should be changed.

OK, I misread that and thought that it was already giving preference to the new setting.

I'm not 100% sure we can make the change, since that in itself wouldn't be backwards-compatible. We should think about how we might make it work, though. Maybe instead of successfully ignoring one of the options we can report an error when we find both?

The current behavior is that the last one always set the value ( it doesn't matter the one is deprecated or not).

I agree with Doug's suggestion , need raise a error when we get more than one names( deprecated or not).
This can help operators find what's wrong in their config options.

seems this bug no longer exists,

code:
        cfg.StrOpt('a',
                    default='a',
                    help='help a'),
        cfg.StrOpt('b',
                    default='b',
                    help='help b',
                   deprecated_name='a'),

conf:
# help a (string value)
a = aa

# help b (string value)
# Deprecated group/name - [api]/a
b = bb

print all opts:
2016-08-03 17:05:25.144 17262 INFO __main__ [-] a = aa
2016-08-03 17:05:25.152 17262 INFO __main__ [-] b = bb

The example in the previous comment does not necessarily show that the bug is fixed. Per ChangBo's earlier comment, "The current behavior is that the last one always set the value" so because b is after a in the example file it will always take precedence.

If the example in #5 is how the options are configured, then this is a use error in the application using the library.

When "b" is marked as deprecating "a" the option definition for "a" should be removed. That tells oslo.config that when a program accesses the "b" option if it doesn't find the value it should look under the name "a" as a fallback.

[Expired for oslo.config because there has been no activity for 60 days.]