Open Stack

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