On Tue, May 16, 2017 at 06:57:04AM -0700, Michał Jastrzębski wrote: > 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). > > Issue with that is > > 1. Apache served is harder to use because we want to follow docker API > and we'd have to reimplement it
No, the idea is apache is transparent, for now we have been using proxypass module in apache. I think what Doug was mentioning was have a primary docker registery, with is RW for a publisher, then proxy it to regional mirrors as RO. > 2. Running registry is single command > I've seen this mentioned a few times before, just because it is one command or 'simple' to do, doesn't mean we want to or can. Currently our infrastructure is complicated, for various reasons. I am sure we'll get to the right technical solution for making jobs happy. Remember our infrastructure spans 6 clouds and 15 regions and want to make sure it is done correctly. > 3. If we host in in infra, in case someone actually uses it (there > will be people like that), that will eat up lot of network traffic > potentially We can monitor this and adjust as needed. > 4. With local caching of images (working already) in nodepools we > loose complexity of mirroring registries across nodepools > > So bottom line, having dockerhub/quay.io is simply easier. > See comment above. > > 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 __________________________________________________________________________ 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