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