Excerpts from Michael Bayer's message of 2017-07-18 13:21:30 -0400: > On Tue, Jul 18, 2017 at 1:02 PM, Doug Hellmann <d...@doughellmann.com> wrote: > > > Option renaming was originally meant as an operatior-facing feature > > to handle renames for values coming from the config file, but not > > as they are used in code. mtreinish added > > https://review.openstack.org/#/c/357987/ to address this for Tempest, > > so it's possible there's a bug in the logic in oslo.config somewhere > > (or that oslo.db's case is a new one). > > OK, patch set 5 at > https://review.openstack.org/#/c/334182/5/oslo_db/options.py shows > what I'm trying to do to make this work, however the test case added > in test_options still fails. If this is supposed to "just work" then > I hope someone can confirm that.
You found a bug related to the fact that these options are registered using an OptGroup() not just a simple string name. https://review.openstack.org/484897 should fix it. > > Alternatively, a simple flag in DeprecatedOpt "alias_on_conf=True" > would be super easy here so that specific names in our DeprecatedOpt > could be mirrored because we know projects are consuming them on conf. > > > > > That said, the options defined by a library are *NOT* part of its > > API, and should never be used by code outside of the library. The > > whole point of isolating options like that is to give operators a > > way to change the way an app uses a library (drivers, credentials, > > etc.) without the app having to know the details. Ideally the nova > > tests that access oslo.db configuration options directly would > > instead use an API in oslo.db to do the same thing (that API may > > need to be written, if it doesn't already exist). > > OK, that is I suppose an option, but clearly a long and arduous one at > this point (add new API to oslo.db, find all projects looking at > conf., submit gerrits, somehow make sure projects never talk to > conf.<name> directly? how would we ensure that? shouldn't > oslo.config allow the library that defines the options to plug in its > own "private" namespace so that consuming projects don't make this > mistake?) > > > > > At that point, only oslo.db code would refer to the option, and you > > could use the deprecated_name and deprecated_group settings to > > describe the move and change the references to oslo.db within the > > library using a single patch to oslo.db. > > > > Doug > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev