Open Stack

On 4/24/16, 10:05 PM, "Tomasz Pa" <ss7pro at gmail.com> wrote:

>On Sat, Apr 23, 2016 at 2:27 AM, Steven Dake (stdake) <stdake at cisco.com>
>wrote:
>>
>> Trying to understand the issue here, do you believe the current jinja2
>> Dockerfiles are not readable?  I'm pretty sure my 11 and 13 year old
>> children which are just learning programming already understand
>>conditionals
>> and variables.  A full-blown DSL for describing container contents
>>seems out
>> of the domain of Kolla's mission, although I'd never say no if someone
>> wanted to give a crack at implementing one.
>
>Kolla images are simply to big and not properly layered. What it means
>that if you today want to upgrade one of the packages: ie: python-nova
>(assuming images are build from RPMs) you're upgrading whole layer
>which contains all it's dependencies added by yum. So at the end
>simple 12MB upgrades turns to be 120MB (right now this is the size of
>the kolla image layer which contains python-nova).
>
>Having some proper DSL for describing container content would mean
>that we can have each package deployed within it's own image layer.
>This would definitely speed up upgrades and would ensure better layer
>sharing between multiple images.
>
>Cheers

I disagree with your assertion.  You are gaming your data to provide the
worst possible container (nova) because the RPMs pull in libvirt.  Kolla
has no control over how Red Hat choses to package RDO, and at this time
they choose to package libvirt as a dependency thereof.  Obviously it
would be more optimal in a proper container system not to include libvirt
in the dependencies installed with Nova.  If you really want that, use
from source installs.  Then you could shave 1 minute off your upgrade time
of a 64 node cluster.

A DSL does not solve this problem unless the DSL contains every dependency
to install (from binary).  I don't see this as maintainable.

But lets talk about how real containers affect outcomes of deployment and
upgrade times without the usage of a DSL.

A centos deployment of Kolla was measured at 25 minutes on a 64 node OSIC
cluster.  An upgrade was measured at 12 minutes.  This is 2-10x faster
then other deployment systems at either upgrade or deployment of the same
cluster size.

Essentially I think you suggest a micro-optimization for nova in the
one-off case of RPM installations, which is taking a sledge hammer to a
needle.  From source doesn't suffer from this problem and no other
containers beyond Nova suffer from this problem either.

But just to put real numbers on this, a deployment of Kolla was measured
at 25 minutes on an OSIC 64 node cluster.

An upgrade was measured at 12 minutes for that same 64 node cluster.

Creating a DSL to optimize for the nova imports libvirt dependency issue
is super-overkill and is a super micro-optimization.

Please provide a better and more relevant example.

Just as a conclusion, deploying each dependency in a separate layer is an
absolutely terrible idea.  Docker performance atleast is negatively
affected by large layer counts, and aufs has a limit of 42 layers, so your
idea is not viable asp resented.

Cheers

>
>__________________________________________________________________________
>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