Open Stack

Excerpts from Michael Bayer's message of 2017-07-18 12:34:31 -0400:
> In oslo.db, I'd like to rename the option "idle_timeout" to
> "connection_recycle_time".
> 
> Following the pattern of using DeprecatedOpt, we get this:
> 
>     cfg.IntOpt('connection_recycle_time',
>                default=3600,
>                deprecated_opts=[cfg.DeprecatedOpt('idle_timeout',
>                                                   group="DATABASE"),
>                                 cfg.DeprecatedOpt('idle_timeout',
>                                                   group="database"),
>                                 cfg.DeprecatedOpt('sql_idle_timeout',
>                                                   group='DEFAULT'),
>                                 cfg.DeprecatedOpt('sql_idle_timeout',
>                                                   group='DATABASE'),
>                                 cfg.DeprecatedOpt('idle_timeout',
>                                                   group='sql')],
> 
> 
> However, Nova is accessing "conf.idle_timeout" directly in
> nova/db/sqlalcemy/api.py -> _get_db_conf.  Tempest run fails.
> 
> Per the oslo.config documentation, the "deprecated_name" flag would
> create an alias on the conf. namespace.  However, this has no effect,
> even if I remove the other deprecated parameters completely:
> 
>     cfg.IntOpt('connection_recycle_time',
>                default=3600,
>                deprecated_name='idle_timeout',
> 
> a simple unit test fails to see a value for
> conf.connection_recycle_time, including if I add
> "deprecated_group='DATABASE'" which is the group that's in this
> specific test (however this would not be a solution anyway because
> projects use different group names).
> 
> From this, it would appear that oslo.config has made it impossible to
> deprecate the name of an option because DeprecatedOpt() has no means
> of providing the value as an alias on the conf. object.   There's not
> even a way I could have projects like nova make a forwards-compatible
> change here.
> 
> Is this a bug in oslo.config or in oslo.db's usage of oslo.confg?
> 

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).

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).

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