Open Stack

Excerpts from Marian Horban's message of 2015-11-04 17:00:55 +0200:
> Hi guys,
> 
> Unfortunately I haven't been on Tokio summit but I know that there was
> discussion about dynamic reloading of configuration.
> Etherpad refs:
> https://etherpad.openstack.org/p/mitaka-cross-project-dynamic-config-services
> ,
> https://etherpad.openstack.org/p/mitaka-oslo-security-logging
> 
> In this thread I want to discuss agreements reached on the summit and
> discuss
> implementation details.
> 
> Some notes taken from etherpad and my remarks:
> 
> 1. "Adding "mutable" parameter for each option."
> "Do we have an option mutable=True on CfgOpt? Yes"
> ---------------------------------------------------------
> As I understood 'mutable' parameter must indicate whether service contains
> code responsible for reloading of this option or not.
> And this parameter should be one of the arguments of cfg.Opt constructor.
> Problems:
> 1. Library's options.
> SSL options ca_file, cert_file, key_file taken from oslo.service library
> could be reloaded in nova-api so these options should be mutable...
> But for some projects that don't need SSL support reloading of SSL options
> doesn't make sense. For such projects this option should be non mutable.
> Problem is that oslo.service - single and there are many different projects
> which use it in different way.
> The same options could be mutable and non mutable in different contexts.

No, that would not be allowed. An option would either always be mutable,
or never. Library options, such as logging levels, would be marked
mutable and the library would need to provide a callback of some sort to
be invoked when the configuration is reloaded. If we can't do this for
SSL-related options, those are not mutable.

> 2. Support of config options on some platforms.
> Parameter "mutable" could be different for different platforms. Some
> options
> make sense only for specific platforms. If we mark such options as mutable
> it could be misleading on some platforms.

Again, if the option cannot be made mutable everywhere it is not
mutable.

> 3. Dependency of options.
> There are many 'workers' options(osapi_compute_workers, ec2_workers,
> metadata_workers, workers). These options specify number of workers for
> OpenStack API services.
> If value of the 'workers' option is greater than '1' instance of
> ProcessLauncher is created otherwise instance of ServiceLauncher is created.
> When ProcessLauncher receives SIGHUP it reloads it own configuration,
> gracefully terminates children and respawns new children.
> This mechanism allows to reload many config options implicitly.
> But if value of the 'workers' option equals '1' instance of ServiceLauncher
> is created.
> ServiceLauncher starts everything in single process and in this case we
> don't have such implicit reloading.
> 
> I think that mutability of options is a complicated feature and I think that
> adding of 'mutable' parameter into cfg.Opt constructor could just add mess.

The idea is to start with a very small number of options. Most of the
ones identified in the summit session are owned by the application,
if I remember correctly. After the configuration changes, the same
function that calls the reload for oslo.config would call the necessary
reload functions in the libraries and application modules that have
mutable options.

> 
> 2. "oslo.service catches SIGHUP and calls oslo.config"
> ---------------------------------------------------------
> From my point of view every service should register list of hooks to reload
> config options. oslo.service should catch SIGHUP and call list of
> registered
> hooks one by one with specified order.
> Discussion of such implementation was started in ML:
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074558.html

The reload hooks may need to be called in a specific order, so for
now we're leaving it up to the application to do that, rather than
having a generic registry.

> .
> Raw reviews:
> https://review.openstack.org/#/c/228892/,
> https://review.openstack.org/#/c/223668/.
> 
> 3. "oslo.config is responsible to log changes which were ignored on SIGHUP"
> ---------------------------------------------------------
> Some config options could be changed using API(for example quotas)
> that's
> why
> oslo.config doesn't know actual configuration of service and can't log
> changes of configuration.

This proposal only applies to options defined by oslo.config, which
should not be duplicated in the database.

Doug