<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 19, 2014 at 9:18 AM, Thomas Bechtold <span dir="ltr"><<a href="mailto:thomasbechtold@jpberlin.de" target="_blank">thomasbechtold@jpberlin.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 18.12.2014 14:03, Thomas Goirand wrote:<br>
> Jeremy,<br>
><br>
> Thanks *A LOT* for writing this up. This is very helpful.<br>
><br>
> On 12/18/2014 09:57 AM, Jeremy Stanley wrote:<br>
>> During the first half of yesterday's cross-project meeting, we went<br>
>> through the sample configuration packaging/publishing topic to get a<br>
>> better idea of what options are open to us. Many thanks to all who<br>
>> attended. The meeting summary with a link to the full discussion<br>
>> logs can be found here:<br>
>><br>
>> <URL: <a href="http://eavesdrop.openstack.org/meetings/crossproject/2014/crossproject.2014-12-16-21.01.html" target="_blank">http://eavesdrop.openstack.org/meetings/crossproject/2014/crossproject.2014-12-16-21.01.html</a> ><br>
>><br>
>> We spent a fair amount of time discussing the current configuration<br>
>> model and the challenges presented by its design, particularly that<br>
>> the presence or absence of different libraries (and differing<br>
>> versions thereof) influence what configuration options are available<br>
>> in a service, the values to which they can be set, and in some cases<br>
>> those to which they default when otherwise omitted. I don't want to<br>
>> go into further detail on that within this thread, but feel<br>
>> obligated to point out that this model is to some extent the result<br>
>> of earlier operational complaints about having to modify too many<br>
>> different configuration files to set up a single service.<br>
>><br>
>> We debated the merits and drawbacks of a number of options proposed<br>
>> here and within the meeting. Before I go into them I'm compelled to<br>
>> remind everyone that none of these comes without some cost in<br>
>> development effort and ongoing management overhead, and ask that<br>
>> anyone who expresses a preference for one or more to include<br>
>> concrete use case descriptions. Things we can consider implementing:<br>
>><br>
>> 1. Standardize on a common mechanism across all projects to generate<br>
>> sample configuration files. This should be able to run within a<br>
>> global system context, not just within a virtualenv via tox.<br>
><br>
> Yes please! I'm already using what tox does, instead of tox itself. IMO,<br>
> this should go into oslo.config (or some kind of lib like this).<br>
<br>
</div></div>There is already oslo-config-generator (<br>
<a href="http://docs.openstack.org/developer/oslo.config/generator.html" target="_blank">http://docs.openstack.org/developer/oslo.config/generator.html</a> ). That<br>
should imho be used and is already in use by some projects.<br>
<span class=""><br></span></blockquote><div><br></div><div><div style="font-size:12.7272720336914px">This is how we're making the Configuration Reference each release [1] but for swift, we wrote a special scraper. [2]</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">There are some requirements for any of the solutions so we don't lose what we already have with the Configuration Reference:</div><div style="font-size:12.7272720336914px">- version shown in the output</div><div style="font-size:12.7272720336914px">- indication of new, changed, and deprecated options</div><div style="font-size:12.7272720336914px">- default values and units</div><div style="font-size:12.7272720336914px">- meaningful descriptions for each setting [3]</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">Thanks,</div><div style="font-size:12.7272720336914px">Anne</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">1. <a href="http://docs.openstack.org/juno/config-reference/content/" target="_blank">http://docs.openstack.org/juno/config-reference/content/</a></div><div style="font-size:12.7272720336914px">2. <a href="http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/extract_swift_flags.py" target="_blank">http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/extract_swift_flags.py</a></div><div style="font-size:12.7272720336914px">3. <a href="http://docs.openstack.org/juno/config-reference/content/container-sync-realms-configuration.html" target="_blank">http://docs.openstack.org/juno/config-reference/content/container-sync-realms-configuration.html</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>> 2. Provide a solution which runs within the scope of each project's<br>
>> setup.py to generate sample configuration and include it in any<br>
>> sdist tarball or Python wheel. This would have the added benefit<br>
>> that people installing via pip from PyPI or just retrieving official<br>
>> tarballs would get copies of sample configuration from the timeframe<br>
>> when they were generated. As this complicates sdist generation<br>
>> (because it requires installation of required and optional libraries<br>
>> used by the service), it probably needs to be easy to enable and<br>
>> disable.<br>
><br>
> As you know, I don't care about the sdist tarballs, but I do want<br>
> "python setup.py install" to generate the config files. Otherwise, a<br>
> "python setup.py config-file" or something similar would do, as long as<br>
> it is:<br>
> 1/ Documented<br>
> 2/ Consistent across all of OpenStack<br>
<br>
</span>Yes. And generating the sample-config during the sdist run and including<br>
it into the sdist or wheel file doesn't fix the issue with the<br>
<span class="">consistency of libs.<br>
<br>
>> 3. Design a Sphinx plug-in or other similar solution to generate and<br>
>> include sample configuration files within the developer<br>
>> documentation of each project. Since this documentation is<br>
>> automatically updated and published, it would provide a stable<br>
>> location where interested parties can view and download these files<br>
>> without needing to manually generate or extract them from an<br>
>> archive.<br>
><br>
> This doesn't fix the issue with the consistency of libs.<br>
><br>
>> 4. Set up a service that periodically regenerates sample<br>
>> configuration and tracks it over time. This attempts to address the<br>
>> stated desire to be able to see how sample configurations change,<br>
>> but note that this is a somewhat artificial presentation since there<br>
>> are a lot of variables (described earlier) influencing the contents<br>
>> of such samples--any attempt to render it as a linear/chronological<br>
>> series could be misleading.<br>
><br>
> Same issue.<br>
><br>
>> Anyway, this is just an attempt to level-set and spur the discussion<br>
>> onward to actionable solutions rather than continuing to debate in<br>
>> the abstract. Hopefully it takes us in a good direction.<br>
><br>
> Let's just hope we'll experience consistency.<br>
><br>
<br>
</span>Cheers,<br>
<br>
Tom<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div></div></div>