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) _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators