[openstack-dev] [magnum] Discuss the blueprint"support-private-registry"

Eli Qiao liyong.qiao at intel.com
Thu Mar 31 00:41:22 UTC 2016


Sound good if bp /allow-user-softwareconfig/ 
<https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig>can 
support configure CA, if it can be land, then I am going to drop this bp 
/support-private-registry (which is insceure)
/but for now, I need to use patches for /support-private-registry /for 
my local testing stuff.

Looking forwarding for patches of /allow-user-softwareconfig

BR, Eli
/
On 2016年03月30日 22:20, Kai Qiang Wu 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.
>
>
>
>
> Thanks
>
> Best Wishes,
> --------------------------------------------------------------------------------
> Kai Qiang Wu (吴开强 Kennan)
> IBM China System and Technology Lab, Beijing
>
> E-mail: wkqwu at 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!
>
> 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 at Ricardo Rocha ---30/03/2016 09:09:14 pm---Hi. On Wed, Mar 
> 30, 2016 at 3:59 AM, Eli Qiao <liyong.qiao at intel.com> wrote:
>
> From: Ricardo Rocha <rocha.porto at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at 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.qiao at 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-request at 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-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
>
>
>
>
>
> __________________________________________________________________________
> 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

-- 
Best Regards, Eli Qiao (乔立勇)
Intel OTC China

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/3ef15db3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/3ef15db3/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liyong_qiao.vcf
Type: text/x-vcard
Size: 123 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/3ef15db3/attachment.vcf>


More information about the OpenStack-dev mailing list