Hi all,
This mail is to serve as a follow on to the discussion during
yesterday's team meeting[4], which was regarding the desire to move
start scripts out of the kolla images [0]. There's a few factors at
play, and it may well be best left to discuss in person at the summit in
May, but hopefully we can get at least some of this hashed out before then.
I'll start by summarising why I think this is a good idea, and then
attempt to address some of the concerns that have come up since.
First off, to be frank, this is effort is driven by wanting to add
support for loci images[1] in kolla-ansible. I think it would be
unreasonable for anyone to argue this is a bad objective to have, loci
images have very obvious benefits over what we have in Kolla today. I'm
not looking to drop support for Kolla images at all, I simply want to
continue decoupling things to the point where operators can pick and
choose what works best for them. Stemming from this, I think moving
these scripts out of the images provides a clear benefit to our
consumers, both users of kolla and third parties such as triple-o. Let
me explain why.
Normally, to run a docker image, a user will do 'docker run
helloworld:latest'. In any non trivial application, config needs to be
provided. In the vast majority of cases this is either provided via a
bind mount (docker run -v hello.conf:/etc/hello.conf helloworld:latest),
or via environment variables (docker run --env HELLO=paul
helloworld:latest). This is all bog standard stuff, something anyone
who's spent an hour learning docker can understand.
Now, lets say someone wants to try out OpenStack with Docker, and they
look at Kolla. First off they have to look at something called
set_configs.py[2] - over 400 lines of Python. Next they need to
understand what that script consumes, config.json [3]. The only
reference for config.json is the files that live in kolla-ansible, a
mass of jinja and assumptions about how the service will be run. Next,
they need to figure out how to bind mount the config files and
config.json into the container in a way that can be consumed by
set_configs.py (which by the way, requires the base kolla image in all
cases). This is only for the config. For the service start up command,
this need to also be provided in config.json. This command is then
parsed out and written to a location in the image, which is consumed by
a series of start/extend start shell scripts. Kolla is *unique* in this
regard, no other project in the container world is interfacing with
images in this way. Being a snowflake in this regard is not a good
thing. I'm still waiting to hear from a real world operator who would
prefer to spend time learning the above to doing:
docker run -v /etc/keystone:/etc/keystone keystone:latest
--entrypoint /usr/bin/keystone [args]
This is the Docker API, it's easy to understand and pretty much the
standard at this point.
The other argument is that this removes the possibility for immutable
infrastructure. The concern is, with the new approach, a rookie operator
will modify one of the start scripts - resulting in uncertainty that
what was first deployed matches what is currently running. But with the
way Kolla is now, an operator can still do this! They can restart
containers with a custom entrypoint or additional bind mounts, they can
exec in and change config files, etc. etc. Kolla containers have never
been immutable and we're bending over backwards to artificially try and
make this the case. We cant protect a bad or inexperienced operator from
shooting themselves in the foot, there are better ways of doing so.
If/when Docker or the upstream container world solves this problem, it
would then make sense for Kolla to follow suit.
On the face of it, what the spec proposes is a simple change, it should
not radically pull the carpet out under people, or even change the way
kolla-ansible works in the near term. If consumers such as tripleo or
other parties feel it would in fact do so please do let me know and we
can discuss and mitigate these problems.
Cheers,
-Paul
[0] https://review.openstack.org/#/c/550958/
[1] https://github.com/openstack/loci
[2]
https://github.com/openstack/kolla/blob/master/docker/base/set_configs.py
[3]
https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/keystone/templates/keystone.json.j2
[4]
http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-04-04-16.00.log.txt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
