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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
