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