Excerpts from Davanum Srinivas (dims)'s message of 2017-05-23 10:44:30 -0400: > Team, > > Background: > For projects based on Go and Containers we need to ship binaries, for
Can you elaborate on the use of the term "need" here. Is that because otherwise the projects can't be consumed? Is it the "norm" for projects from those communities? Something else? > 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 What are the support lifetimes for those images? Who maintains them? > 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) I see how this would work for Go builds, since we would be tagging the thing being built. My understanding is that Kolla images are using the Kolla version, not the version of the software inside the image, though. How would that work? (Or maybe I misunderstood something from another thread and that's not how the images are versioned?) > * Just like we upload stuff to tarballs.openstack.org, we will upload > binaries and containers there as well I know there's an infra spec for doing some of this, so I assume we anticipate having the storage capacity needed? > * 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. > > Please note that I am deliberately ruling out the following > * Daily/Nightly releases that are accessible to end users, especially > from stable branches. The Kolla team did seem to want periodic builds for testing (to avoid having to build images in the test pipeline, IIUC). Do we still want to build those to tarballs.o.o? Does that even meet the needs of those test jobs? > * Project teams directly responsible for pushing stuff to end users > > What do you think? > > Thanks, > Dims > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
