Open Stack

Folks,
=====

I've got a dilemma right now about how to proceed with containerising
ironic-inspector:

Fat Container
------------------
put ironic-inspector and dnsmasq into a single container i.e consider a
container as a complete inspection service shipping unit, use supervisord
inside to fork and monitor both the services.

Pros:

* decoupling: dnsmasq of inspector isn't used by any other service which
makes our life simpler as we won't need to reset dnsmasq configuration in
case inspector died (to avoid exposing an unfiltered DHCP service)

* we can use dnsmasq filter (an on-line configuration files updating
facility) driver to limit access to dnsmasq instead of iptables, in a
self-contained "package" that is configured to work together as a single
unit

* we don't have to worry about always scheduling dnsmasq and inspector
containers on a single node (both services are bundled)

* we have a *Spine-Leaf deployment capable & containerised undercloud*

* an *HA capable inspector* service to be reused in overcloud

* an integrated solution, tested to work by upstream CI in inspector
(compatibility, versioning, configuration,...)

Cons:

* inflexibility: container has to be rebuilt to be used with different DHCP
service (filter driver)

* supervisord dependency and the need to refactor current container of
inspector

* <put your input here>

Flat Container
-------------------

Put inspector and dnsmasq into separate containers. Use the (current)
iptables driver to protect dnsmasq. IIRC this is the current approach.

Pros:

* containerised undercloud

Cons:

* no decoupling of dnsmasq

* no spine-leaf (iptables)

* containers have to be scheduled together on a single node,

* no HA (iptables driver)

* container won't be cool for overcloud as it won't be HA

Flat container with dnsmasq filter driver
----------------------------------------------------

Same as above but iptables isn't used anymore. Since it's not the current
approach, we'd have to reshape the containers of dnsmasq and inspector to
expose each others configuration so that inspector can write dnsmasq
configuration on the fly (does inotify work in the mounted directories
case???)

Pros:

* containerised undercloud

* Spine-Leaf

Cons:

* No (easy) HA (dnsmasq would be exposed in case inspector died)

* No decoupling of dnsmasq (shared between multiple services)

* containers to be reshaped to expose the configuration

* overcloud-uncool container (lack of HA)

No Container
------------------

we ship inspector as a service and configure dnsmasq for inspector to be
shut down in case inspector dies (to prevent exposing an unfiltered DHCP
service interference). We use dnsmasq (configuration) filter driver to have
a Spine-Leaf deployment capable undercloud.

Pros:

* Spine&Leaf

Cons:

* no HA inspector (shared dnsmasq?)

* no containers

* no reusable container for overcloud

* we'd have to update the undercloud systemd to shut down dnsmasq in case
inspector dies if we want to use the dnsmasq filter driver

* no decoupling

The Question
------------------

What is your take on it?

Cheers,
milan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171101/1df0a05f/attachment.html>