Open Stack

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.

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