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