Responses inline :) I started snipping parts out because the quotations
are getting long.
<snip>
tl;dr use kolla images and bootsrap OR upstream images with
direct
commands:
.. code-block:: yaml
kolla_config:
/var/lib/kolla/config_files/foo.json
command: /usr/bin/foo
We insist on using kolla extended start, if only it can't function
w/o Kolla extended start using Kolla images (like Mysql and Rabbitmq
have some extra initialization)
I don't think we need to insist on this, in fact i'd even prefer not
using kolla_start in cases where it doesn't provide significant value.
In addition to the Kolla flavor that Dan mentioned earlier, using these
entrypoints also increases chance of TripleO being broken by a commit to
Kolla, because Kolla commits aren't gated on deploying TripleO.
If the only thing we need is the file permissions setup, we don't even
need to use kolla_start for that, we can use kolla_set_configs [4]
directly in an init container. (But again, i don't think we need to
force this as a rule.)
vs
.. code-block:: yaml
foo:
image: upstream/foo:latest
command: /usr/bin/foo
We accept direct commands as well, if it works w/o "user: root" for
Kolla containers omitting extended start OR if it just works as is with
upstream containers (non Kolla), like etcd [2] and perhaps redis
I think using direct commands is fine.
However, i think we should avoid targeting any images that we can't
build ourselves easily. One of the benefits of using Kolla images is a
uniform way how to build them.
<snip>
* Custom entrypoints for containers adds complexity and head ache.
Good point. But the entry points Kolla uses for many containers don't
match what our systemd services already use on baremetal. As we are
striving for update path that does not break end users upgrading from
baremetal to containers we have to have a mechanism that gives us
configuration parity across the implementions. Controlling the entry
point either by injecting it into the container (via something like
Kolla's template overrides mechanism) or via tripleo-heat-templates
direction (much more hackable) is where we ended up.
Yea i'd very much prefer using entrypoints that are easily amendable by
TripleO developers, and are gated on deploying TripleO.
As for having them in-image or externally passed from t-h-t, that could
almost be a thread on its own :) The benefit of t-h-t approach is
hackability. The benefit of in-image approach is being sure that the
image version is compatible with its entrypoint (for rollbacks and such)
and generally the image being more self contained (being able to use it
easier manually, without Heat/t-h-t, should the need arise).
I think we may still be forming our opinion on this matter as we hit
issues with one or the other approach, maybe we'll even continue using
different approaches for different use cases.
In general we like Kolla images at the moment for what they provide.
But there are some cases where we need to control things that have too
much of a "kolla flavor" and would potentially break upgrades/features
if we used them directly.
We accept custom entry points for some tricky cases as well.
Having that said, I'd really like to see a final call for that topic.
Otherwise it's really hard to do a code review and perhaps to maintain
changes to t-h-t for future releases as well.
Cheers
Jirka
[4]
https://github.com/openstack/kolla/blob/77903c70cd651ad97a6a918f6889e5120d85b8d1/docker/base/start.sh#L14
__________________________________________________________________________
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
