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