It’s worthwhile to talk the current goals of Loci and how they relate to the project release. Loci is a set of Dockerfiles and scripts that builds OpenStack service containers from source. Loci can target container builds for three distributions (Ubuntu, CentOS, and Suse) and for all of the major OpenStack services. By default builds are from HEAD of master from each project, but can be set to build from stable project branches. What does this mean for release management of Loci? As of right now, any API changes to Loci remain backwards compatible. If you are using Loci to build container images, you will most likely benefit from running from master. We haven't made an official a release of Loci because that would imply that we believed an end user would benefit from a stable release point. So far, the Loci team has not felt that way. However, there is the possibility that for auditing purposes one would want to know the exact code that was used to build container images. To this end we'll discuss possible release version process at our weekly meeting tomorrow. If you are a user or potential user of Loci and have an opinion about this, please attend the meeting tomorrow (Friday November 30 at 1500 UTC in the #openstack-loci channel) or reply to this thread. There's also the possibility that to add major new features, like building container images from packages rather than source, we will have to introduce major API changes which would be useful to signal to end users. Right now no work has been done to advance package builds. As for artifacts created by Loci. The Loci gate publishes images to Docker Hub as part of its testing process. These are builds of OpenStack services from HEAD of master for each of these projects, and should not be used in production. The Loci team strongly encourages consumers of Loci containers to build and maintain their own image sets. This is considered best practice for security and maintainability. To answer your question, as of right now we are at 2: "not meant to be "released" or tagged but more like continuously published". This may change after the meeting tomorrow. Thanks, Chris
On Nov 29, 2018, at 2:38 AM, Thierry Carrez <thierry@openstack.org> wrote:
Hi, loci folks,
The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise.
As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external".
In that context, the situation of the loci deliverable (openstack/loci repository) is unclear. Is it:
1. meant to be released through the openstack/releases repository, but just not ready yet (any hint of when it will be ?)
2. not meant to be "released" or tagged but more like continuously published (in which case we should add "release-management:none" to it)
3. meant to be released, but on a 3rd-party platform like the Docker Hub and not using openstack/releases to drive it (in which case we should add "release-management:external" to it)
From previous discussions it appears (2) would best describe the loci situation, but I wanted to doublecheck it was still the case.
Thanks,
-- Thierry Carrez (ttx)