Re: [openstack-dev] [Magnum]Cache docker images

2016-04-20 Thread Ricardo Rocha 
Hi.

On Wed, Apr 20, 2016 at 5:43 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> If the ops are deploying a cloud big enough to run into that problem, I
> think they can deploy a scaled out docker registry of some kind too, that
> the images can point to? Last I looked, it didn't seem very difficult. The
> native docker registry has ceph support now, so if your running ceph for the
> backend, you can put an instance on each controller and have it stateless I
> think.

This is what we did, using registry v2. There's an issue to pull from
a v2 registry anonymously:
https://github.com/docker/docker/issues/17317

but we've setup a dummy account to do it. Both this account and any
required CA certs can be configured by the operator, which was the
reasoning to propose (we patch the templates for now):
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig

Allowing an optional prefix to pull from a local registry sounds reasonable.

Cheers,
  Ricardo

>
> Either way you would be hammering some storage service. Either glance or
> docker registry.
>
> Thanks,
> Kevin
> 
> From: Guz Egor [guz_e...@yahoo.com]
> Sent: Tuesday, April 19, 2016 7:20 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Fox, Kevin M
> Subject: Re: [openstack-dev] [Magnum]Cache docker images
>
> Kevin,
>
> I agree this is not ideal solution, but it's probably the best option to
> deal with public cloud "stability" (e.g. we switched to the same model at
> AWS and
> got really good boost in provisioning time and reduce # failures during
> cluster provisioning). And if application need guarantee "fresh" image, it
> uses
> force pull option in Marathon.
>
> ---
> Egor
>
> 
> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Sent: Tuesday, April 19, 2016 1:04 PM
>
> Subject: Re: [openstack-dev] [Magnum]Cache docker images
>
> I'm kind of uncomfortable as an op with the prebundled stuff. how do you
> upgrade things when needed if there is no way to pull updated images from a
> central place?
>
> Thanks,
> Kevin
> ________________
> From: Hongbin Lu [hongbin...@huawei.com]
> Sent: Tuesday, April 19, 2016 11:56 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Magnum]Cache docker images
>
> Eli,
>
> The approach of pre-pulling docker images has a problem. It only works for
> specific docker storage driver. In comparison, the tar file approach is
> portable across different storage drivers.
>
> Best regards,
> Hongbin
>
> From: taget [mailto:qiaoliy...@gmail.com]
> Sent: April-19-16 4:26 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum]Cache docker images
>
> hi hello again
>
> I believe you are talking about this bp
> https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
> then ignore my previous reply, that may another topic to solve network
> limited problem.
>
> I think you are on the right way to build docker images but this image could
> only bootstrap by cloud-init, without cloud-init
> the container image tar file are not loaded at all, but seems this may not
> be the best way.
>
> I'v suggest that may be the best way is we pull docker images while building
> atomic-image. Per my understanding, the
> image build process is we mount the image to read/write mode to some tmp
> directory and chroot to to that dircetory,
> we can do some custome operation there.
>
> I can do a try on the build progress(guess rpm-ostree should support some
> hook scripts)
>
> On 2016年04月19日 11:41, Eli Qiao wrote:
>
> @wanghua
>
> I think there were some discussion already , check
> https://blueprints.launchpad.net/magnum/+spec/support-private-registry
> and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
> On 2016年04月19日 10:57, 王华 wrote:
>
> Hi all,
>
> We want to eliminate pulling docker images over the Internet on bay
> provisioning. There are two problems of this approach:
> 1. Pulling docker images over the Internet is slow and fragile.
> 2. Some clouds don't have external Internet access.
>
> It is suggested to build all the required images into the cloud images to
> resolved the issue.
>
> Here is a solution:
> We export the docker images as tar files, and put the tar files into a dir
> in the image when we build the image. And we add scripts to load the tar
> files in cloud-init, so that we don't need to download the docker images.
>
> Any advi

Re: [openstack-dev] [Magnum]Cache docker images

2016-04-20 Thread Hongbin Lu 


From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: April-20-16 9:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

Hongbin,

Both of approaches you suggested may only work for one binary format. If you 
try to use docker on a different system architecture, the pre-cache of images 
makes it even more difficult to get the correct images built and loaded.

I assume there are ways to detect the system architecture and kernel 
information when we are using disk-imagebuilder to build the image? If yes, we 
can catch the mismatch of system architecture and/or other kernel compatibility 
issues at the early stage.

I suggest we take an approach that allows the Baymodel creator to specify a 
docker registry and/or prefix that will determine where docker images are 
pulled from if they are not found in the local cache. That would give cloud 
operators the option to set up such a registry locally and populate it with the 
right images. This approach would also make it easier to customize the Magnum 
setup by tweaking the container images prior to use.

Works for me.


Thanks,

Adrian

On Apr 19, 2016, at 11:58 AM, Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:
Eli,

The approach of pre-pulling docker images has a problem. It only works for 
specific docker storage driver. In comparison, the tar file approach is 
portable across different storage drivers.

Best regards,
Hongbin

From: taget [mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum]Cache docker images

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network limited 
problem.

I think you are on the right way to build docker images but this image could 
only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may not be 
the best way.

I'v suggest that may be the best way is we pull docker images while building 
atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,
we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support some hook 
scripts)


On 2016年04月19日 11:41, Eli Qiao wrote:
@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
On 2016年04月19日 10:57, 王华 wrote:
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

Best Regards, Eli Qiao (乔立勇)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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]Cache docker images

2016-04-20 Thread Fox, Kevin M 
If the ops are deploying a cloud big enough to run into that problem, I think 
they can deploy a scaled out docker registry of some kind too, that the images 
can point to? Last I looked, it didn't seem very difficult. The native docker 
registry has ceph support now, so if your running ceph for the backend, you can 
put an instance on each controller and have it stateless I think.

Either way you would be hammering some storage service. Either glance or docker 
registry.

Thanks,
Kevin

From: Guz Egor [guz_e...@yahoo.com]
Sent: Tuesday, April 19, 2016 7:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Fox, Kevin M
Subject: Re: [openstack-dev] [Magnum]Cache docker images

Kevin,

I agree this is not ideal solution, but it's probably the best option to deal 
with public cloud "stability" (e.g. we switched to the same model at AWS and
got really good boost in provisioning time and reduce # failures during cluster 
provisioning). And if application need guarantee "fresh" image, it uses
force pull option in Marathon.

---
Egor


From: "Fox, Kevin M" <kevin@pnnl.gov>
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Sent: Tuesday, April 19, 2016 1:04 PM
Subject: Re: [openstack-dev] [Magnum]Cache docker images

I'm kind of uncomfortable as an op with the prebundled stuff. how do you 
upgrade things when needed if there is no way to pull updated images from a 
central place?

Thanks,
Kevin

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Tuesday, April 19, 2016 11:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

Eli,

The approach of pre-pulling docker images has a problem. It only works for 
specific docker storage driver. In comparison, the tar file approach is 
portable across different storage drivers.

Best regards,
Hongbin

From: taget [mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum]Cache docker images

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network limited 
problem.

I think you are on the right way to build docker images but this image could 
only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may not be 
the best way.

I'v suggest that may be the best way is we pull docker images while building 
atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,
we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support some hook 
scripts)

On 2016年04月19日 11:41, Eli Qiao wrote:
@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
On 2016年04月19日 10:57, 王华 wrote:
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Best Regards, Eli Qiao (乔立勇)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-

Re: [openstack-dev] [Magnum]Cache docker images

2016-04-20 Thread Adrian Otto 
Hongbin,

Both of approaches you suggested may only work for one binary format. If you 
try to use docker on a different system architecture, the pre-cache of images 
makes it even more difficult to get the correct images built and loaded.

I suggest we take an approach that allows the Baymodel creator to specify a 
docker registry and/or prefix that will determine where docker images are 
pulled from if they are not found in the local cache. That would give cloud 
operators the option to set up such a registry locally and populate it with the 
right images. This approach would also make it easier to customize the Magnum 
setup by tweaking the container images prior to use.

Thanks,

Adrian

On Apr 19, 2016, at 11:58 AM, Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:

Eli,

The approach of pre-pulling docker images has a problem. It only works for 
specific docker storage driver. In comparison, the tar file approach is 
portable across different storage drivers.

Best regards,
Hongbin

From: taget [mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum]Cache docker images

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network limited 
problem.

I think you are on the right way to build docker images but this image could 
only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may not be 
the best way.

I'v suggest that may be the best way is we pull docker images while building 
atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,
we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support some hook 
scripts)

On 2016?04?19? 11:41, Eli Qiao wrote:
@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
On 2016?04?19? 10:57, ?? wrote:
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Best Regards, Eli Qiao (???)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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]Cache docker images

2016-04-19 Thread Guz Egor 
Kevin, I agree this is not ideal solution, but it's probably the best option to 
deal with public cloud "stability" (e.g. we switched to the same model at AWS 
andgot really good boost in provisioning time and reduce # failures during 
cluster provisioning). And if application need guarantee "fresh" image, it uses 
 force pull option in Marathon.
--- Egor
  From: "Fox, Kevin M" <kevin@pnnl.gov>
 To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org> 
 Sent: Tuesday, April 19, 2016 1:04 PM
 Subject: Re: [openstack-dev] [Magnum]Cache docker images
   
#yiv4843844425 #yiv4843844425 _filtered #yiv4843844425 {font-family:SimSun;} 
_filtered #yiv4843844425 {} _filtered #yiv4843844425 {font-family:Calibri;} 
_filtered #yiv4843844425 {font-family:Tahoma;} _filtered #yiv4843844425 
{font-family:Consolas;}#yiv4843844425 p.yiv4843844425MsoNormal, #yiv4843844425 
li.yiv4843844425MsoNormal, #yiv4843844425 div.yiv4843844425MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv4843844425 
a:link, #yiv4843844425 span.yiv4843844425MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv4843844425 a:visited, #yiv4843844425 
span.yiv4843844425MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv4843844425 pre 
{margin:0cm;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv4843844425 
span.yiv4843844425HTMLPreformattedChar 
{font-family:Consolas;color:black;}#yiv4843844425 
span.yiv4843844425EmailStyle19 {color:#1F497D;}#yiv4843844425 
.yiv4843844425MsoChpDefault {font-size:10.0pt;} _filtered #yiv4843844425 
{margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv4843844425 #yiv4843844425 P 
{margin-top:0;margin-bottom:0;}I'm kind of uncomfortable as an op with the 
prebundled stuff. how do you upgrade things when needed if there is no way to 
pull updated images from a central place?

Thanks,
Kevin
From: Hongbin Lu [hongbin...@huawei.com]
Sent: Tuesday, April 19, 2016 11:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

Eli, The approach of pre-pulling docker images has a problem. It only works for 
specific docker storage driver. In comparison, the tar file approach is 
portable across different storage drivers. Best regards,Hongbin From: taget 
[mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum]Cache docker images hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network limited 
problem.

I think you are on the right way to build docker images but this image could 
only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may not be 
the best way.

I'v suggest that may be the best way is we pull docker images while building 
atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,
we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support some hook 
scripts)

On 2016年04月19日 11:41, Eli Qiao wrote:
@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfigOn 
2016年04月19日 10:57,王华 wrote:
Hi all,  We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:1. Pulling docker images 
over the Internet is slow and fragile.2. Some clouds don't have external 
Internet access. It is suggested to build all the required images into the 
cloud images to resolved the issue. Here is a solution:We export the docker 
images as tar files, and put the tar files into a dir in the image when we 
build the image. And we add scripts to load the tar files in cloud-init, so 
that we don't need to download the docker images. Any advice for this solution 
or any better solution? Regards,Wanghua


__OpenStack
 Development Mailing List (not for usage questions)Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- Best Regards, Eli Qiao (乔立勇)
__
OpenStack Develop

Re: [openstack-dev] [Magnum]Cache docker images

2016-04-19 Thread Fox, Kevin M 
I'm kind of uncomfortable as an op with the prebundled stuff. how do you 
upgrade things when needed if there is no way to pull updated images from a 
central place?

Thanks,
Kevin

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Tuesday, April 19, 2016 11:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

Eli,

The approach of pre-pulling docker images has a problem. It only works for 
specific docker storage driver. In comparison, the tar file approach is 
portable across different storage drivers.

Best regards,
Hongbin

From: taget [mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum]Cache docker images

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network limited 
problem.

I think you are on the right way to build docker images but this image could 
only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may not be 
the best way.

I'v suggest that may be the best way is we pull docker images while building 
atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,
we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support some hook 
scripts)

On 2016年04月19日 11:41, Eli Qiao wrote:
@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
On 2016年04月19日 10:57, 王华 wrote:
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Best Regards, Eli Qiao (乔立勇)
__
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]Cache docker images

2016-04-19 Thread Fox, Kevin M 
If they have a valid CA signed cert for the docker registry, it should 'Just 
work (TM)' :)

Self signing is a different issue. Maybe just an additional option in addition 
to the prefix option to pass a CA to add to the root trust chain?

Thanks,
Kevin


From: Hongbin Lu [hongbin...@huawei.com]
Sent: Tuesday, April 19, 2016 11:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

Yes, that is an alternative. The complication is how to secure the 
communication between Magnum bays and the standalone docker registry. I assume 
we needs some custom logic to setup the communication channel (i.e. install the 
TLS credential). One way to support it is to add a configuration hook [1] that 
allows operators to customize the setup. Pre-built docker images into the 
glance image is another approach. I think Magnum can offer both.

[1] https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig

Best regards,
Hongbin

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: April-19-16 1:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

why not just allow a prefix to be added to the container name?

you can then have a container named:
foo/mycontainer

and the prefix could be set to mylocalserver.org:8080:
mylocalserver.org:8080/foo/mycontainer

Then if the site needs local only containers, they can set up a local repo. Be 
it a stand alone docker registry, the docker datacenter product, artifactory 
with the docker plugin, etc.

Thanks,
Kevin

From: 王华 [wanghua.hum...@gmail.com]
Sent: Monday, April 18, 2016 7:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum]Cache docker images
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua
__
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]Cache docker images

2016-04-19 Thread Hongbin Lu 
Eli,

The approach of pre-pulling docker images has a problem. It only works for 
specific docker storage driver. In comparison, the tar file approach is 
portable across different storage drivers.

Best regards,
Hongbin

From: taget [mailto:qiaoliy...@gmail.com]
Sent: April-19-16 4:26 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum]Cache docker images

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network limited 
problem.

I think you are on the right way to build docker images but this image could 
only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may not be 
the best way.

I'v suggest that may be the best way is we pull docker images while building 
atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,
we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support some hook 
scripts)

On 2016年04月19日 11:41, Eli Qiao wrote:
@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
On 2016年04月19日 10:57, 王华 wrote:
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Best Regards, Eli Qiao (乔立勇)
__
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]Cache docker images

2016-04-19 Thread Hongbin Lu 
Yes, that is an alternative. The complication is how to secure the 
communication between Magnum bays and the standalone docker registry. I assume 
we needs some custom logic to setup the communication channel (i.e. install the 
TLS credential). One way to support it is to add a configuration hook [1] that 
allows operators to customize the setup. Pre-built docker images into the 
glance image is another approach. I think Magnum can offer both.

[1] https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig

Best regards,
Hongbin

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: April-19-16 1:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum]Cache docker images

why not just allow a prefix to be added to the container name?

you can then have a container named:
foo/mycontainer

and the prefix could be set to mylocalserver.org:8080:
mylocalserver.org:8080/foo/mycontainer

Then if the site needs local only containers, they can set up a local repo. Be 
it a stand alone docker registry, the docker datacenter product, artifactory 
with the docker plugin, etc.

Thanks,
Kevin

From: 王华 [wanghua.hum...@gmail.com]
Sent: Monday, April 18, 2016 7:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum]Cache docker images
Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua
__
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]Cache docker images

2016-04-19 Thread Fox, Kevin M 
why not just allow a prefix to be added to the container name?

you can then have a container named:
foo/mycontainer

and the prefix could be set to mylocalserver.org:8080:
mylocalserver.org:8080/foo/mycontainer

Then if the site needs local only containers, they can set up a local repo. Be 
it a stand alone docker registry, the docker datacenter product, artifactory 
with the docker plugin, etc.

Thanks,
Kevin

From: 王华 [wanghua.hum...@gmail.com]
Sent: Monday, April 18, 2016 7:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum]Cache docker images

Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:
1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images to 
resolved the issue.

Here is a solution:
We export the docker images as tar files, and put the tar files into a dir in 
the image when we build the image. And we add scripts to load the tar files in 
cloud-init, so that we don't need to download the docker images.

Any advice for this solution or any better solution?

Regards,
Wanghua
__
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]Cache docker images

2016-04-19 Thread taget 

hi hello again

I believe you are talking about this bp 
https://blueprints.launchpad.net/magnum/+spec/cache-docker-images
then ignore my previous reply, that may another topic to solve network 
limited problem.


I think you are on the right way to build docker images but this image 
could only bootstrap by cloud-init, without cloud-init
the container image tar file are not loaded at all, but seems this may 
not be the best way.


I'v suggest that may be the best way is we pull docker images while 
building atomic-image. Per my understanding, the
image build process is we mount the image to read/write mode to some tmp 
directory and chroot to to that dircetory,

we can do some custome operation there.

I can do a try on the build progress(guess rpm-ostree should support 
some hook scripts)



On 2016年04月19日 11:41, Eli Qiao wrote:

@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and 
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig 


On 2016年04月19日 10:57, 王华 wrote:

Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:

1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud 
images to resolved the issue.


Here is a solution:
We export the docker images as tar files, and put the tar files into 
a dir in the image when we build the image. And we add scripts to 
load the tar files in cloud-init, so that we don't need to download 
the docker images.


Any advice for this solution or any better solution?

Regards,
Wanghua


__
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


--
Best Regards, Eli Qiao (乔立勇)

__
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]Cache docker images

2016-04-18 Thread Eli Qiao 

@wanghua

I think there were some discussion already , check 
https://blueprints.launchpad.net/magnum/+spec/support-private-registry
and 
https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig 



On 2016年04月19日 10:57, 王华 wrote:

Hi all,

We want to eliminate pulling docker images over the Internet on bay 
provisioning. There are two problems of this approach:

1. Pulling docker images over the Internet is slow and fragile.
2. Some clouds don't have external Internet access.

It is suggested to build all the required images into the cloud images 
to resolved the issue.


Here is a solution:
We export the docker images as tar files, and put the tar files into a 
dir in the image when we build the image. And we add scripts to load 
the tar files in cloud-init, so that we don't need to download the 
docker images.


Any advice for this solution or any better solution?

Regards,
Wanghua


__
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