Open Stack

FYI, in the current implementation, a single image seems
big, around 300MB - 1G. But when push all the image to
the registry service, you will find that the total size
of the images is just 2GB. When distribute the image, It
just takes less 30s to transfer images( 2GB / 100MB/s < 30s ).

This is what the Steve said above. Kolla leverage the docker
parent image and the total size of the images is smaller than
you think.


On Mon, Apr 25, 2016 at 4:49 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> I really hadnt thought about distro deps for non containers leaking into
> containers like nova->libvirt. What about making a kolla-container rpm that
> provides a virtual libvirt package and anything else not actually needed in
> the container?
>
> Thanks,
> Kevin
>
> ------------------------------
> *From:* Steven Dake (stdake)
> *Sent:* Monday, April 25, 2016 1:01:16 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [kolla][kubernetes] Mirantis participation
> in kolla-mesos project and shift towards Kubernetes
>
> Tomasz,
> Response inline.
>
> On 4/25/16, 12:32 AM, "Tomasz Pa" <ss7pro at gmail.com> wrote:
>
> >On Mon, Apr 25, 2016 at 5:51 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
> >wrote:
> >>
> >> I do not think this is the issue of Kolla. It is a issue of Docker
> >> images. All the docker images has such issue. This should be solved
> >> in the docker side.
> >>
> >
> >It's a kolla issue and they way project build images. Calling yum
> >install in Dockerfile is not the best idea (you endup with multiple
> >dependent packages put into the single image layer). Having some good
> >DSL would mean that you can place each package into separate image
> >layer (ie: RUN rpm -i ./python-nova-XXXX.rpm) and take advantage of
> >that during build (reusing cached layers).
>
> In the case were there are a common set of packages that end up in every
> layer, Kolla has optimized for the general build and use case by
> extracting the commonly used dependencies into a base image used by all
> containers.
>
> Reference from binary:
> https://github.com/openstack/kolla/blob/master/docker/openstack-base/Docker
> file.j2#L129
>
>
> Reference from source:
> https://github.com/openstack/kolla/blob/master/docker/openstack-base/Docker
> file.j2#L320
>
>
> Kolla developers essentially count the number of times that requests
> package would be installed in a dependent container, and if it reaches a
> threshold, Kolla installs it in a parent image of every openstack-service
> container.
>
> I agree it is possible to end up with multiple same dependencies in
> different containers, which is why we have this openstack-base image in
> the first place - to serve as a MACRO optimization to solve the very
> problem you point out.
>
> I fail to see how a DSL would improve on this master openstack-base image.
>
> My build times on my gear are 14 minutes for 115+ containers.  I do have
> Intel 750 NVME SSD and gige internet, however, even folks with slower
> storage and networking report 30-35 minute build times which are in the
> window of "not too long to do once in awhile".
>
> But I'll grant you, I personally think every time I rebuild all my images
> on my host I could be doing something better with my time.  I just don't
> think a DSL would help speed up build times as you have claimed, except
> for the one-off case of nova (because of its dependency on libvirt).
>
> What I'd hate to see happen is a DSL invented and used in Kolla that
> specifies each specific dependency to install for binary-packaging.  That
> is what rpm/deb is designed to handle.
>
> For the case of source builds, requirements.txt serves the same purpose.
>
> Regards
> -steve
>
> >
> >
> >--
> >Tomasz Paszkowski
> >SS7, Asterisk, SAN, Datacenter, Cloud Computing
> >+48500166299
> >
> >__________________________________________________________________________
> >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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160425/b16810d6/attachment.html>