Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700: > On 16 May 2017 at 06:20, Flavio Percoco <fla...@redhat.com> wrote: > > On 16/05/17 14:08 +0200, Thierry Carrez wrote: > >> > >> Flavio Percoco wrote: > >>> > >>> From a release perspective, as Doug mentioned, we've avoided releasing > >>> projects > >>> in any kind of built form. This was also one of the concerns I raised > >>> when > >>> working on the proposal to support other programming languages. The > >>> problem of > >>> releasing built images goes beyond the infrastructure requirements. It's > >>> the > >>> message and the guarantees implied with the built product itself that are > >>> the > >>> concern here. And I tend to agree with Doug that this might be a problem > >>> for us > >>> as a community. Unfortunately, putting your name, Michal, as contact > >>> point is > >>> not enough. Kolla is not the only project producing container images and > >>> we need > >>> to be consistent in the way we release these images. > >>> > >>> Nothing prevents people for building their own images and uploading them > >>> to > >>> dockerhub. Having this as part of the OpenStack's pipeline is a problem. > >> > >> > >> I totally subscribe to the concerns around publishing binaries (under > >> any form), and the expectations in terms of security maintenance that it > >> would set on the publisher. At the same time, we need to have images > >> available, for convenience and testing. So what is the best way to > >> achieve that without setting strong security maintenance expectations > >> for the OpenStack community ? We have several options: > >> > >> 1/ Have third-parties publish images > >> It is the current situation. The issue is that the Kolla team (and > >> likely others) would rather automate the process and use OpenStack > >> infrastructure for it. > >> > >> 2/ Have third-parties publish images, but through OpenStack infra > >> This would allow to automate the process, but it would be a bit weird to > >> use common infra resources to publish in a private repo. > >> > >> 3/ Publish transient (per-commit or daily) images > >> A "daily build" (especially if you replace it every day) would set > >> relatively-limited expectations in terms of maintenance. It would end up > >> picking up security updates in upstream layers, even if not immediately. > >> > >> 4/ Publish images and own them > >> Staff release / VMT / stable team in a way that lets us properly own > >> those images and publish them officially. > >> > >> Personally I think (4) is not realistic. I think we could make (3) work, > >> and I prefer it to (2). If all else fails, we should keep (1). > > > > > > Agreed #4 is a bit unrealistic. > > > > Not sure I understand the difference between #2 and #3. Is it just the > > cadence? > > > > I'd prefer for these builds to have a daily cadence because it sets the > > expectations w.r.t maintenance right: "These images are daily builds and not > > certified releases. For stable builds you're better off building it > > yourself" > > And daily builds are exactly what I wanted in the first place:) We > probably will keep publishing release packages too, but we can be so > called 3rd party. I also agree [4] is completely unrealistic and I > would be against putting such heavy burden of responsibility on any > community, including Kolla. > > While daily cadence will send message that it's not stable, truth will > be that it will be more stable than what people would normally build > locally (again, it passes more gates), but I'm totally fine in not > saying that and let people decide how they want to use it. > > So, can we move on with implementation?
I don't want the images published to docker hub. Are they still useful to you if they aren't published? Doug > > Thanks! > Michal > > > > > Flavio > > > > -- > > @flaper87 > > Flavio Percoco > > > > __________________________________________________________________________ > > 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