Open Stack

Dan, Martin, Jiri, and all folks, how could we make a final call for
this please?
The decision impacts code review for new patches, like redis [0] or etcd [1]

[0] https://review.openstack.org/#/c/442151/
[1] https://review.openstack.org/#/c/447627/

As I see (suggest) it:

On 04.04.2017 22:53, Dan Prince wrote:
> On Tue, 2017-04-04 at 18:03 +0200, Bogdan Dobrelya wrote:
>> On 03.04.2017 21:01, Dan Prince wrote:
>>> On Mon, 2017-04-03 at 16:15 +0200, Bogdan Dobrelya wrote:
>>>> Let's please re-evaluate configuration of containerized non-
>>>> openstack,
>>>> like database, message queue, key value, web, services for
>>>> tripleo
>>>> heat
>>>> templates and Kolla. Here is an example containerized etcd patch
>>>> [0].
>>>>
>>>> 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)


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

[2] https://quay.io/repository/coreos/etcd

>> [tl;dr] kolla_config is a bad fit for logs, let's run containers'
>> steps
>> as 'user: root' in a user namespace remapped [1] for a
>> tripleocontainers

If a container wants its main entry point to be run as a root, like the
example upstream etcd image expects, we shall accept that if only tht
root is remapped [3] to some system (e.g. tripleocontainers) user
namespace done for docker

[3] https://goo.gl/HtDQYk

>> * 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.
> 
> 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.


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando