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

[Hongbin Lu]

Ricardo,

Thanks for the willingness to implement the blueprint. I am looking forward to 
reviewing the implementation.

Best regards,
Hongbin

From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
Sent: March-30-16 10:59 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Discuss the 
blueprint"support-private-registry"

Hi.

On Wed, Mar 30, 2016 at 4:20 PM, Kai Qiang Wu 
<wk...@cn.ibm.com<mailto: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<mailto: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!

[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<mailto:liyong.q...@intel.com>> wrote:

From: Ricardo Rocha <rocha.po...@gmail.com<mailto:rocha.po...@gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto: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<mailto: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<http://gcr.io> directly, after 
> checking our
> cloud-init script, I see that
>
> lots of code are *hard coded* to using gcr.io<http://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<http://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<http://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<http://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 wi

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

[Eli Qiao]

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: 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!

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’

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

[Kai Qiang Wu]

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: 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!



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 inse

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

[Ricardo Rocha]

Hi.

On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao  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

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

[Eli Qiao]

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/



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