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