Open Stack

On 23/05/17 10:44 -0400, Davanum Srinivas wrote:
>Team,
>
>Background:
>For projects based on Go and Containers we need to ship binaries, for
>example Kubernetes, etcd both ship binaries and maintain stable
>branches as well.
>  https://github.com/kubernetes/kubernetes/releases
>  https://github.com/coreos/etcd/releases/
>
>Kubernetes for example ships container images to public registeries as well:
>  https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/hyperkube?pli=1
>  https://github.com/kubernetes/kubernetes/tree/master/cluster/images/hyperkube
>
>So here's a proposal based on the really long thread:
>http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677
>
>The idea is to augment the existing processes for the new deliverables.
>
>* Projects define CI jobs for generating binaries and containers (some
>already do!)
>* Release team automation will kick builds off when specific versions
>are released for the binaries and containers (Since Go based projects
>can do cross-builds, we won't need to run these jobs on multiple
>architectures which will keep the release process simple)
>* Just like we upload stuff to tarballs.openstack.org, we will upload
>binaries and containers there as well

If we upload the containers to a registry repo, I'm not sure we need to upload
them here too. This would also take too much space for not much gain since
consumers of these containers won't pull from tarballs.o.o but the registry
itself.

>* Just like we upload things to pypi, we will upload containers with
>specific versions to public repos.
>* Projects can choose from the existing release models to make this
>process as frequent as they need.

If releasing binaries is introduced, I think all projects that can produce
binaries (go, container images), should do it. I'd like this to be consistent.
We generate tarballs for every project, not some of them.

>Please note that I am deliberately ruling out the following
>* Daily/Nightly releases that are accessible to end users, especially
>from stable branches.
>* Project teams directly responsible for pushing stuff to end users
>
>What do you think?

Without giving it too much thought and almost at the end of my day, I think I
like it. One thing to consider is that we'll also need a process to define what
kind of binaries we build and/or ship. I don't think we want to build rpms/debs
or other distro packages. Therefore, we need to explicitly list the type of
binaries we build.

As long as the binaries produced don't introduce any kind of bias, I think I'm
good.

Thanks for sending this out,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170523/d98e2cd1/attachment.sig>