Open Stack

On Fri, Dec 19, 2014 at 9:18 AM, Thomas Bechtold <thomasbechtold at jpberlin.de
> 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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141219/ae25f769/attachment.html>