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

Thomas Goirand zigo at debian.org
Tue Oct 10 19:48:31 UTC 2017


On 10/09/2017 12:36 PM, Jesse Pretorius wrote:
> There has been an objection from the OpenStack package maintainer for
> Debian, but that objection has been to the use of the relative path of
> /etc. Thomas Goirand, could you please indicate whether you support the
> use of the relative path of /share given the currently available
> functionality in setuptools and pbr?

See my other post, which is IMO the most important and that we may have
missed in this thread: I don't think data_files is there to handle
configuration files, but *only* data_file. Probably Monty will be able
to confirm that fact. If one day, we want to mix data files (ie, things
to push in /usr/share, typically) and config files, then everything will
fall apart.

So, maybe we should design a config_files statement in setup.cfg?

>> 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;

Historically, I believe it's there because I started to do so in Debian,
and then Ubuntu people picked-up what I did for a few project, then
thought it wasn't a bad idea.

Also, there's an important bit too: we're patching keystonemiddleware so
that it includes the old type of keystone auth variables when generating
the config files. Here's the patch:

https://anonscm.debian.org/cgit/openstack/libs/python-keystonemiddleware.git/tree/debian/patches/re-add-missing-auth-options.patch

FYI, this is very important for Debian's CI, as it's still using the old
type of keystone auth and expecting correct configuration files. Even if
it was using the new type (ie: keystone v3), then something would need
to be patched in keystonemiddleware to generate that (as currently,
keystonemiddleware entry point produces ... no auth directive at all!).
BTW, the use of default config files in the CI is very intentional on my
side, as I do want to test them. Over the years, I realized Debian was
the *only* distro in the world that was gating on that. I did notice it
when I understood nobody else was reporting bugs about them. Other
distros are probably using config management scripts, I guess.

So anyway, the point was: we'd better regenerate all service's config
file by ourselves to make sure it's really taking into account our
patch. I also prefer to have config files wrapped with 140 columns
rather than the default 80. That's only my opinionated preference, and
just an example of why we may prefer to do things by ourselves.

> 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.

Well, if OpenStack as an upstream was doing everything correctly, it'd
be a huge win. Though really, the correct way to do things is to give
package maintainers the freedom to do what they want. In this case,
giving a way to tell "please drop my config files THERE --->", so that
we can write nice automations is the correct thing to do.

> As mentioned in [4] these should be auto-generated. Some projects do
> this and submit samples into the repo from time to time, others have
> just left a stub with an explanation of how to generate it.

The correct thing to do is to *not* ship potentially wrong samples.
Indeed, the config files depend on the version of the underlying libs,
which can potentially change without prior notice. But let's not rehash
this again, it has been written *many* times over *multiple* years. :)

>> I'd also beĀ +1 on a packaging SIG;

I might have missed it, but what is SIG?!?

> This
> e-mail message may contain confidential or privileged information
> intended for the recipient. Any dissemination, distribution or copying
> of the enclosed material is prohibited. If you receive this transmission
> in error, please notify us immediately by e-mail at abuse at rackspace.com
> and delete the original message. Your cooperation is appreciated.

Hum... Should I mention that this message footer is inappropriate for a
*public* mailing list? Will I be persecuted for quoting you? :)

Cheers,

Thomas Goirand (zigo)



More information about the OpenStack-dev mailing list