Open Stack

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).

> 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

> 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.

Thomas Goirand (zigo)