Open Stack

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