<div dir="ltr">Hi Bogdan,<div><br></div><div>thanks for the response!</div><div>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.<br><br><div class="gmail_quote"><div dir="ltr">čt 2. 11. 2017 v 9:54 odesílatel Bogdan Dobrelya <<a href="mailto:bdobreli@redhat.com">bdobreli@redhat.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/1/17 7:04 PM, milanisko k wrote:<br>
> Folks,<br>
> =====<br>
><br>
> I've got a dilemma right now about how to proceed with containerising<br>
> ironic-inspector:<br>
><br>
> Fat Container<br>
> ------------------<br>
> put ironic-inspector and dnsmasq into a single container i.e consider a<br>
> container as a complete inspection service shipping unit, use<br>
> supervisord inside to fork and monitor both the services.<br>
><br>
> Pros:<br>
><br>
> * decoupling: dnsmasq of inspector isn't used by any other service which<br>
> makes our life simpler as we won't need to reset dnsmasq configuration<br>
> in case inspector died (to avoid exposing an unfiltered DHCP service)<br>
><br>
> * we can use dnsmasq filter (an on-line configuration files updating<br>
> facility) driver to limit access to dnsmasq instead of iptables, in a<br>
> self-contained "package" that is configured to work together as a single<br>
> unit<br>
><br>
> * we don't have to worry about always scheduling dnsmasq and inspector<br>
> containers on a single node (both services are bundled)<br>
><br>
> * we have a *Spine-Leaf deployment capable & containerised undercloud*<br>
><br>
> * an *HA capable inspector* service to be reused in overcloud<br>
><br>
> * an integrated solution, tested to work by upstream CI in inspector<br>
> (compatibility, versioning, configuration,...)<br>
><br>
> Cons:<br>
><br>
> * inflexibility: container has to be rebuilt to be used with different<br>
> DHCP service (filter driver)<br>
><br>
> * supervisord dependency and the need to refactor current container of<br>
> inspector<br>
><br>
> * <put your input here><br>
><br>
> Flat Container<br>
> -------------------<br>
><br>
> Put inspector and dnsmasq into separate containers. Use the (current)<br>
> iptables driver to protect dnsmasq. IIRC this is the current approach.<br>
><br>
> Pros:<br>
><br>
> * containerised undercloud<br>
><br>
> Cons:<br>
><br>
> * no decoupling of dnsmasq<br>
><br>
> * no spine-leaf (iptables)<br>
><br>
> * containers have to be scheduled together on a single node,<br>
><br>
> * no HA (iptables driver)<br>
><br>
> * container won't be cool for overcloud as it won't be HA<br>
><br>
> Flat container with dnsmasq filter driver<br>
> ----------------------------------------------------<br>
><br>
> Same as above but iptables isn't used anymore. Since it's not the<br>
> current approach, we'd have to reshape the containers of dnsmasq and<br>
> inspector to expose each others configuration so that inspector can<br>
> write dnsmasq configuration on the fly (does inotify work in the mounted<br>
> directories case???)<br>
><br>
> Pros:<br>
><br>
> * containerised undercloud<br>
><br>
> * Spine-Leaf<br>
><br>
> Cons:<br>
><br>
> * No (easy) HA (dnsmasq would be exposed in case inspector died)<br>
<br>
Could it be managed by pacemaker bundles then?</blockquote><div> </div><div>  would you recommend that?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> * No decoupling of dnsmasq (shared between multiple services)<br>
<br>
A dedicated side-car container can be used, just like the logging bp [0]<br>
implements it. So nothing will be shared then.<br>
<br>
[0] <a href="https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog</a><br>
<br></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> * containers to be reshaped to expose the configuration<br>
<br>
Seems like this is inevitable anyway</blockquote><div><br></div><div>  probably not in the case of the fat container</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> * overcloud-uncool container (lack of HA)<br>
<br>
Could it be managed by pacemaker bundles then?</blockquote><div> 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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> No Container<br>
> ------------------<br>
><br>
> we ship inspector as a service and configure dnsmasq for inspector to be<br>
> shut down in case inspector dies (to prevent exposing an unfiltered DHCP<br>
> service interference). We use dnsmasq (configuration) filter driver to<br>
> have a Spine-Leaf deployment capable undercloud.<br>
><br>
> Pros:<br>
><br>
> * Spine&Leaf<br>
><br>
> Cons:<br>
><br>
> * no HA inspector (shared dnsmasq?)<br>
><br>
> * no containers<br>
><br>
> * no reusable container for overcloud<br>
><br>
> * we'd have to update the undercloud systemd to shut down dnsmasq in<br>
> case inspector dies if we want to use the dnsmasq filter driver<br>
><br>
> * no decoupling<br>
><br>
> The Question<br>
> ------------------<br>
><br>
> What is your take on it?<br>
><br>
> Cheers,<br>
> milan<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>