Open Stack

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 <doug at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>