Open Stack

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.

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.

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.

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.

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