Open Stack

On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote:
> The closer we can get logic about what a service should look like on
> disk back into that service itself, the less work duplicated by any of
> the installers, and the more common OpenStack envs would be. The fact
> that every installer / package needs to copy in a bunch of etc files
> (because the python packages don't do it) has always seemed rather odd
> to me.

I agree with this, and given the disparate and seemingly contradictory
goals driving these discussions, I think it will be exceedingly
difficult to make everyone happy. So here's my suggestion:

1. Maintain all important data for packaging as first-class members of
   the respective repositories. Initscripts, systemd service files,
   licensing (SPDX?), and so on should be in the master branch of each
   project. Just enough glue should be present such that functional
   packaging can be programmatically generated from HEAD with debdry or
   similar tooling, and this is how test jobs should operate (f.ex.: run
   debdry, mangle version number to something unique, build package in
   chroot or equivalent, store output for use in other testing).

2. Create a single repository, with one subdirectory per "source
   package", in which overrides or patches to third-party packaging can
   be committed and used to trigger builds.

This way OpenStack could

-  produce and consume its own package artifacts for testing changes of
   varying complexity
-  get early warning of changes which will break packaging, insanity in
   dependency graphs, and so on
-  be a central point of collaboration without introducing a bunch of
   repo duplication or bypass of code review

Distributors could

-  clone the upstream repos and branch to add any special tweaks, then
   potentially run the same automation to get source/binary packages
-  collaborate upstream to fix things of common utility