>> 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.
That would also work, yes >> 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. And that's why we discussed dockerhub. Remember that I was willing to implement proper registry, but we decided to go with dockerhub simply because it puts less stress on both infra and infra team. And I totally agree with that statement. Dockerhub publisher + apache caching was our working idea. >> 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 __________________________________________________________________________ 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
