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

.@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

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

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

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

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 t

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

er. 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] [

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

need guarantee "fresh" image, it uses  force pull option in Marathon. --- Egor From: "Fox, Kevin M" To: OpenStack Development Mailing List (not for usage questions) Sent: Tuesday, April 19, 2016 1:04 PM Subject: Re: [openstack-dev] [Magnum]Cache docker images #yiv

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

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 diff

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

_ 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 Magnu

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

: 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

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

] 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

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

: [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.

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 b

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

@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月

[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 i