On 4/24/16, 10:05 PM, "Tomasz Pa" <[email protected]> wrote:
>On Sat, Apr 23, 2016 at 2:27 AM, Steven Dake (stdake) <[email protected]> >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: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
