Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
I've been out on vacation but as a circle back to normal (working!) life I've found this thread very interesting. I share the concerns raised about the level of resource required to back this. I don't speak for the VMT but I agree with Jeremy that it should be possible to provide VMT support to Kolla and their code base without extending to the external libraries in their contain images. However, I'm not sure that the limits of VMT coverage would be acceptable to downstream stakeholders, for the reasons Doug has highlighted above. Perhaps it would be useful for a spec around this, so we could collaborate in a more structured way? -Rob On Wed, May 24, 2017 at 3:54 PM, Jeremy Stanley wrote: > On 2017-05-24 14:22:14 +0200 (+0200), Thierry Carrez wrote: > [...] > > we ship JARs already: > > http://tarballs.openstack.org/ci/monasca-common/ > [...] > > Worth pointing out, those all have "SNAPSHOT" in their filenames > which by Apache Maven convention indicates they're not official > releases. Also they're only being hosted from our > tarballs.openstack.org site, not published to the Maven Central > Repository (the equivalent of DockerHub in this analogy). > > > That said, only a small fraction of our current OpenStack deliverables > > are supported by the VMT and therefore properly security-maintained "by > > the community" with strong guarantees and processes. So I don't see > > adding such binary deliverables (maintained by their respective teams) > > as a complete revolution. I'd expect the VMT to require a lot more > > staffing (like dedicated people to track those deliverables content) > > before they would consider those security-supported. > > The Kolla team _has_ expressed interest in attaining > vulnerability:managed for at least some of their deliverables in the > future, but exactly what that would look like from a coverage > standpoint has yet to be ironed out. I don't expect we would > actually cover general vulnerabilities present in any container > images, and would only focus on direct vulnerabilities in the Kolla > source repositories instead. Rather than extending the VMT to track > vulnerable third-party software present in images, it's more likely > the Kolla team would form their own notifications subgroup to track > and communicate such risks downstream. > -- > Jeremy Stanley > > __ > 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 > > __ 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
Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
On 2017-05-24 14:22:14 +0200 (+0200), Thierry Carrez wrote: [...] > we ship JARs already: > http://tarballs.openstack.org/ci/monasca-common/ [...] Worth pointing out, those all have "SNAPSHOT" in their filenames which by Apache Maven convention indicates they're not official releases. Also they're only being hosted from our tarballs.openstack.org site, not published to the Maven Central Repository (the equivalent of DockerHub in this analogy). > That said, only a small fraction of our current OpenStack deliverables > are supported by the VMT and therefore properly security-maintained "by > the community" with strong guarantees and processes. So I don't see > adding such binary deliverables (maintained by their respective teams) > as a complete revolution. I'd expect the VMT to require a lot more > staffing (like dedicated people to track those deliverables content) > before they would consider those security-supported. The Kolla team _has_ expressed interest in attaining vulnerability:managed for at least some of their deliverables in the future, but exactly what that would look like from a coverage standpoint has yet to be ironed out. I don't expect we would actually cover general vulnerabilities present in any container images, and would only focus on direct vulnerabilities in the Kolla source repositories instead. Rather than extending the VMT to track vulnerable third-party software present in images, it's more likely the Kolla team would form their own notifications subgroup to track and communicate such risks downstream. -- Jeremy Stanley signature.asc Description: Digital 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
Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2017-05-23 10:44:30 -0400: >> 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? dims will likely answer directly, but I would say because it is the "norm" there. If we were a Java project, we would definitely be publishing JARs, for the exact same reason. Oh, wait. We actually do Java stuff, so we ship JARs already: http://tarballs.openstack.org/ci/monasca-common/ >> 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? That's a good question. Due to various bundling and dependency inclusion, security maintenance on those artifacts is definitely more costly than our usual artifacts. Here by default I would say it's probably best effort from the teams themselves. That said, only a small fraction of our current OpenStack deliverables are supported by the VMT and therefore properly security-maintained "by the community" with strong guarantees and processes. So I don't see adding such binary deliverables (maintained by their respective teams) as a complete revolution. I'd expect the VMT to require a lot more staffing (like dedicated people to track those deliverables content) before they would consider those security-supported. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
On 23 May 2017 at 08:13, Doug Hellmann wrote: > 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?) Currently tagging is not fully answered question. Depends what cadence/method for pushing we'll end up with. But since one image can have multiple tags, we can do several at once. We can tag with :pike, pike-2 (rev number), and :version-of-main-component, all pointing to same image. >> * 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 One thing to consider here is exactly same issue which was moved in different thread, maybe even to higher degree. Golang binaries will have their binaries built into it, so if one of deps has CVE, whole binary will have it. Higher degree, because while containers can have manifest of versions built into it, golang doesn't really (versioning of deps in golang is actually quite tricky thing). If we want to ship these binaries, they will have same dangers as images pushed to dockerhub. >> What do you think? >> >> Thanks, >> Dims >> > > __ > 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 __ 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
Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
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
[openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
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 * 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. * Project teams directly responsible for pushing stuff to end users What do you think? Thanks, Dims -- Davanum Srinivas :: https://twitter.com/dims __ 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
