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