Open Stack

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 at 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)
>