<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
we actually had a solution implemented in Ceilometer to handle
this[1].<br>
<br>
that said, based on the results of our survey[2], we found that most
operators *never* update configuration files after the initial setup
and if they did it was very rarely (monthly updates). the question
related to Ceilometer and its pipeline configuration file so the
results might be specific to Ceilometer. I think you should
definitely query operators before undertaking any work. the last
thing you want to do is implement a feature no one really
needs/wants.<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/reload-file-based-pipeline-configuration.html">http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/reload-file-based-pipeline-configuration.html</a><br>
[2]
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2015-September/075628.html">http://lists.openstack.org/pipermail/openstack-dev/2015-September/075628.html</a><br>
<br>
<div class="moz-cite-prefix">On 04/11/2015 10:00 AM, Marian Horban
wrote:<br>
</div>
<blockquote
cite="mid:CADR2cKQpbrZ+ZeDMraC4ff7h9MCMuDxkTGWVYDNKWOQQ0rQVtQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/228892/">https://review.openstack.org/#/c/228892/</a>, </div>
<div><a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
gord</pre>
</body>
</html>