<div dir="ltr"><div>Hi guys,</div><div><br></div><div>Unfortunately I haven't been on Tokio summit but I know that there was </div><div>discussion about dynamic reloading of configuration.</div><div>Etherpad refs: </div><div><a href="https://etherpad.openstack.org/p/mitaka-cross-project-dynamic-config-services">https://etherpad.openstack.org/p/mitaka-cross-project-dynamic-config-services</a>, </div><div><a href="https://etherpad.openstack.org/p/mitaka-oslo-security-logging">https://etherpad.openstack.org/p/mitaka-oslo-security-logging</a></div><div><br></div><div>In this thread I want to discuss agreements reached on the summit and discuss </div><div>implementation details.</div><div><br></div><div>Some notes taken from etherpad and my remarks:</div><div><br></div><div>1. "Adding "mutable" parameter for each option."</div><div>"Do we have an option mutable=True on CfgOpt? Yes"</div><div>---------------------------------------------------------</div><div>As I understood 'mutable' parameter must indicate whether service contains </div><div>code responsible for reloading of this option or not.</div><div>And this parameter should be one of the arguments of cfg.Opt constructor.</div><div>Problems:</div><div>1. Library's options. </div><div>SSL options ca_file, cert_file, key_file taken from oslo.service library </div><div>could be reloaded in nova-api so these options should be mutable...</div><div>But for some projects that don't need SSL support reloading of SSL options </div><div>doesn't make sense. For such projects this option should be non mutable.</div><div>Problem is that oslo.service - single and there are many different projects </div><div>which use it in different way.</div><div>The same options could be mutable and non mutable in different contexts.</div><div>2. Support of config options on some platforms.</div><div>Parameter "mutable" could be different for different platforms. Some options </div><div>make sense only for specific platforms. If we mark such options as mutable </div><div>it could be misleading on some platforms.</div><div>3. Dependency of options.</div><div>There are many 'workers' options(osapi_compute_workers, ec2_workers, </div><div>metadata_workers, workers). These options specify number of workers for </div><div>OpenStack API services.</div><div>If value of the 'workers' option is greater than '1' instance of </div><div>ProcessLauncher is created otherwise instance of ServiceLauncher is created.</div><div>When ProcessLauncher receives SIGHUP it reloads it own configuration, </div><div>gracefully terminates children and respawns new children.</div><div>This mechanism allows to reload many config options implicitly.</div><div>But if value of the 'workers' option equals '1' instance of ServiceLauncher </div><div>is created.</div><div>ServiceLauncher starts everything in single process and in this case we </div><div>don't have such implicit reloading.</div><div><br></div><div>I think that mutability of options is a complicated feature and I think that</div><div>adding of 'mutable' parameter into cfg.Opt constructor could just add mess.</div><div><br></div><div>2. "oslo.service catches SIGHUP and calls oslo.config"</div><div>---------------------------------------------------------</div><div>From my point of view every service should register list of hooks to reload </div><div>config options. oslo.service should catch SIGHUP and call list of registered </div><div>hooks one by one with specified order.</div><div>Discussion of such implementation was started in ML: </div><div><a href="http://lists.openstack.org/pipermail/openstack-dev/2015-September/074558.html">http://lists.openstack.org/pipermail/openstack-dev/2015-September/074558.html</a>.</div><div>Raw reviews: </div><div><a href="https://review.openstack.org/#/c/228892/">https://review.openstack.org/#/c/228892/</a>, </div><div><a href="https://review.openstack.org/#/c/223668/">https://review.openstack.org/#/c/223668/</a>.</div><div><br></div><div>3. "oslo.config is responsible to log changes which were ignored on SIGHUP"</div><div>---------------------------------------------------------</div><div>Some config options could be changed using API(for example quotas) that's why </div><div>oslo.config doesn't know actual configuration of service and can't log </div><div>changes of configuration.</div><div><br></div><div>Regards, Marian Horban</div></div>