On 16 May 2017 at 06:22, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Thierry Carrez's message of 2017-05-16 14:08:07 +0200: >> 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). >> > > At the forum we talked about putting test images on a "private" > repository hosted on openstack.org somewhere. I think that's option > 3 from your list? > > Paul may be able to shed more light on the details of the technology > (maybe it's just an Apache-served repo, rather than a full blown > instance of Docker's service, for example). > > Doug > > __________________________________________________________________________ > 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