Open Stack

On Tue, May 16, 2017 at 06:57:04AM -0700, Michał Jastrzębski wrote:
> On 16 May 2017 at 06:22, Doug Hellmann <doug at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev