Hi. On Wed, Mar 30, 2016 at 4:20 PM, Kai Qiang Wu <wk...@cn.ibm.com> wrote:
> I agree to that support-private-registry should be secure. As insecure > seems not much useful for production use. > Also I understood the point setup related CA could be diffcult than normal > HTTP, but we want to know if > https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig > > Could address the issue and make templates clearer to understood ? If > related patch or spec proposed, we are glad to review and make it better. > Yes, some local customization of the node setup would be great and help with the CA setup - we're willing to implement that blueprint. Cheers, Ricardo > > > > > Thanks > > Best Wishes, > > -------------------------------------------------------------------------------- > Kai Qiang Wu (吴开强 Kennan) > IBM China System and Technology Lab, Beijing > > E-mail: wk...@cn.ibm.com > Tel: 86-10-82451647 > Address: Building 28(Ring Building), ZhongGuanCun Software Park, > No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 > > -------------------------------------------------------------------------------- > Follow your heart. You are miracle! > > [image: Inactive hide details for Ricardo Rocha ---30/03/2016 09:09:14 > pm---Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao <liyong.qiao@]Ricardo > Rocha ---30/03/2016 09:09:14 pm---Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli > Qiao <liyong.q...@intel.com> wrote: > > From: Ricardo Rocha <rocha.po...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: 30/03/2016 09:09 pm > Subject: Re: [openstack-dev] [magnum] Discuss the blueprint > "support-private-registry" > ------------------------------ > > > > Hi. > > On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao <liyong.q...@intel.com> wrote: > > > > Hi Hongbin > > > > Thanks for starting this thread, > > > > > > > > I initial propose this bp because I am in China which is behind China > great > > wall and can not have access of gcr.io directly, after checking our > > cloud-init script, I see that > > > > lots of code are *hard coded* to using gcr.io, I personally though this > is > > not good idea. We can not force user/customer to have internet access in > > their environment. > > > > I proposed to use insecure-registry to give customer/user (Chinese or > whom > > doesn't have gcr.io access) a chance to switch use their own > > insecure-registry to deploy > > k8s/swarm bay. > > > > For your question: > >> Is the private registry secure or insecure? If secure, how to > handle > >> the authentication secrets. If insecure, is it OK to connect a secure > bay to > >> an insecure registry? > > An insecure-resigtry should be 'secure' one, since customer need to > setup it > > and make sure it's clear one and in this case, they could be a private > > cloud. > > > >> Should we provide an instruction for users to pre-install the private > >> registry? If not, how to verify the correctness of this feature? > > > > The simply way to pre-install private registry is using insecure-resigtry > > and docker.io has very simple steps to start it [1] > > for other, docker registry v2 also supports using TLS enable mode but > this > > will require to tell docker client key and crt file which will make > > "support-private-registry" complex. > > > > [1] https://docs.docker.com/registry/ > > [2]https://docs.docker.com/registry/deploying/ > > 'support-private-registry' and 'allow-insecure-registry' sound different > to me. > > We're using an internal docker registry at CERN (v2, TLS enabled), and > have the magnum nodes setup to use it. > > We just install our CA certificates in the nodes (cp to > etc/pki/ca-trust/source/anchors/, update-ca-trust) - had to change the > HEAT templates for that, and submitted a blueprint to be able to do > similar things in a cleaner way: > https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig > > That's all that is needed, the images are then prefixed with the > registry dns location when referenced - example: > docker.cern.ch/my-fancy-image. > > Things we found on the way: > - registry v2 doesn't seem to allow anonymous pulls (you can always > add an account with read-only access everywhere, but it means you need > to always authenticate at least with this account) > https://github.com/docker/docker/issues/17317 > - swarm 1.1 and kub8s 1.0 allow authentication to the registry from > the client (which was good news, and it works fine), handy if you want > to push/pull with authentication. > > Cheers, > Ricardo > > > > > > > > > On 2016年03月30日 07:23, Hongbin Lu wrote: > > > > Hi team, > > > > > > > > This is the item we didn’t have time to discuss in our team meeting, so I > > started the discussion in here. > > > > > > > > Here is the blueprint: > > https://blueprints.launchpad.net/magnum/+spec/support-private-registry . > Per > > my understanding, the goal of the BP is to allow users to specify the > url of > > their private docker registry where the bays pull the kube/swarm images > (if > > they are not able to access docker hub or other public registry). An > > assumption is that users need to pre-install their own private registry > and > > upload all the required images to there. There are several potential > issues > > of this proposal: > > > > · Is the private registry secure or insecure? If secure, how to > > handle the authentication secrets. If insecure, is it OK to connect a > secure > > bay to an insecure registry? > > > > · Should we provide an instruction for users to pre-install the > > private registry? If not, how to verify the correctness of this feature? > > > > > > > > Thoughts? > > > > > > > > Best regards, > > > > Hongbin > > > > > > > > > __________________________________________________________________________ > > 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 > > > > > > -- > > Best Regards, Eli Qiao (乔立勇) > > Intel OTC China > > > > > > > __________________________________________________________________________ > > 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