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

Doug Hellmann doug at doughellmann.com
Thu Sep 28 16:07:59 UTC 2017

Excerpts from Jesse Pretorius's message of 2017-09-28 14:50:24 +0000:
> There’s some history around this discussion [1], but times have changed and the purpose of the patches I’m submitting is slightly different [2] as far as I can see – it’s a little more focused and less intrusive.
> The projects which deploy OpenStack from source or using python wheels currently have to either carry templates for api-paste, policy and rootwrap files or need to source them from git during deployment. This results in some rather complex mechanisms which could be radically simplified by simply ensuring that all the same files are included in the built wheel. Distribution packagers typically also have mechanisms in place to fetch the files from the source repo when building the packages – including the files through pbr’s data_files for packagers may or may not be beneficial, depending on how the packagers do their build processes.
> In neutron [3], glance [4], designate [5] and sahara [6] the use of the data_files option in the files section of setup.cfg is established and has been that way for some time. However, there have been issues in the past implementing something similar – for example in keystone there has been a bit of a yoyo situation where a patch was submitted, then reverted.
> I’ve been proposing patches [7] to try to make the implementation across projects consistent and projects have, for the most part, been happy to go ahead and merge them. However concern has been raised that we may end up going through another yo-yo experience and therefore I’ve been asked to raise this on the ML.
> Do any packagers or deployment projects have issues with this implementation? If there are any issues, what’re your suggestions to resolve them?
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097123.html
> [2] https://launchpad.net/bugs/1718356
> [3] https://github.com/openstack/neutron/blob/d3c393ff6b5fbd0bdaabc8ba678d755ebfba08f7/setup.cfg#L24-L39
> [4] https://github.com/openstack/glance/blob/02cd5cba70a8465a951cb813a573d390887174b7/setup.cfg#L20-L21
> [5] https://github.com/openstack/designate/blob/25eb143db04554d65efe2e5d60ad3afa6b51d73a/setup.cfg#L30-L37
> [6] https://github.com/openstack/sahara/blob/cff43d6f1eee5c68af16c6f655f4d019669224d9/setup.cfg#L28-L29
> [7] https://review.openstack.org/#/q/topic:bug/1718356+(status:open+OR+status:merged)

In the past we had trouble checking those files into git and gating
against the results being "up to date" or not changing in any way
because configuration options that end up in the file are defined in
libraries used by the services. So as long as the implementation you're
considering does not check configuration files into git, but generates
them and then inserts them into the package, it should be fine.


More information about the OpenStack-dev mailing list