Open Stack

Hi Bogdan,

thanks for the response!
I'm looking for an advice esp. what's going to be the easiest way to
achieve the most value with the least effort here as I'm not an expert and
I don't have a strong opinion.

čt 2. 11. 2017 v 9:54 odesílatel Bogdan Dobrelya <bdobreli at redhat.com>
napsal:

> On 11/1/17 7:04 PM, milanisko k wrote:
> > 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)
>
> Could it be managed by pacemaker bundles then?


  would you recommend that?


>
> >
> > * No decoupling of dnsmasq (shared between multiple services)
>
> A dedicated side-car container can be used, just like the logging bp [0]
> implements it. So nothing will be shared then.
>
> [0] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog
>
> The logging is indeed similar situation, although here's no need to expose
what the inspector and dnsmasq share. So I don't see the added value when
compared to, in my opinion, a simpler solution of a fat container. But I'm
cool if you think that the sidecar is the best way forward here.


> >
> > * containers to be reshaped to expose the configuration
>
> Seems like this is inevitable anyway


  probably not in the case of the fat container


>
>
>
> > * overcloud-uncool container (lack of HA)
>
> Could it be managed by pacemaker bundles then?

 In case pacemaker is configured to do so, most likely that's the case. I'm
cool with what ever is going to be simpler in the end of the day.


>
> >
> > 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
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171103/9661b2c8/attachment.html>