Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160425/d9d1dd89/attachment.html>