On 16 May 2017 at 08:12, Doug Hellmann <d...@doughellmann.com> wrote: > 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?
What do you mean? We need images available...whether it's dockerhub, infra-hosted registry or any other way to have them, we need to be able to have images that are available and fresh without building. Dockerhub/quay.io is least problems for infra team/resources. > 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 __________________________________________________________________________ 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