[openstack-dev] [packaging][all] Sample Config Files in setup.cfg

James Page james.page at ubuntu.com
Fri Oct 6 08:23:29 UTC 2017

On Tue, 3 Oct 2017 at 18:15 Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Jesse Pretorius's message of 2017-10-03 15:57:17 +0000:
> > On 10/3/17, 3:01 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:
> >
> > >> Given that this topic has gone through several cycles of discussion
> and has never gone anywhere, does it perhaps merit definition as a project
> interface so that we can define the problem this is trying to solve and set
> a standard formally once and for all?
> >
> > >    Maybe a couple of the various packaging projects can agree and just
> > >    set a de facto rule (and document it). That worked out OK for us
> > >    with the doc reorganization when we updated the docs.o.o site
> > >    templates.
> >
> > I’m happy to facilitate that. Is there some sort of place where such
> standards are recorded? Ie Where do I submit a review to and is there an
> example to reference for the sort of information that should be in it?
> >
> The docs team put that info in the spec for the migration. Do we
> have a packaging SIG yet? That seems like an ideal body to own a
> standard like this long term. Short term, just getting some agreement
> on the mailing list would be a good start.

Bah - missed the start of this thread but here's my tuppence

1) +1 for a consistent approach across projects - /usr/share/<module>
sounds like a sensible location - avoiding any complexity with managing
changes made by users in /etc/<project> for deploy from source use-cases,
and allowing packagers to know where to expect reference/sample config
files to appear during the package build-out/install process.

2) Looking at the Ubuntu packaging for OpenStack projects, we have quite a
few places where oslo-config-generator or oslo-policy-generator is used to
generate sample configuration files as part of the package build; I might
have missed it in my read through of this thread but it would be awesome if
those could be integrated as part of this process as well as the
originating project would then be able to provide some level for assurance
to the content of generated files in downstream distributions.

I'd also be +1 on a packaging SIG; I don't think it will ever be a high
overhead SIG but it sounds like there are common challenges for deployment
projects and distributors which would benefit from shared focus.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171006/1572126b/attachment.html>

More information about the OpenStack-dev mailing list