<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">út 17. 10. 2017 v 17:14 odesílatel Dan Prince <<a href="mailto:dprince@redhat.com">dprince@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 Tue, 2017-10-17 at 11:46 +0000, milanisko k wrote:<br>
><br>
> How about the shared container? Wouldn't it be better not have to<br>
> rely on t-h-t especially if we're "scheduling" (and probably<br>
> configuring) the services as a single logical entity?<br>
<br>
The containers architecture for Pike and Queens is very much oriented<br>
around preserving the way we deployed the services already on<br>
baremetal... but moving them into containers. So for Ironic inspector</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
we had 2 services (2 systemd scripts) both living in separate<br>
containers. Do the the shared nature of this architecture with regards<br>
to network and host access this works fine.<br></blockquote><div><br></div><div>Unless new features, such as  the inspector support for routed/relayed DHCP/PXE traffic (or spine&leaf network topology), come  into the question. </div><div>For this case, as well as for the HA case (with non-overlapping dnsmasq DHCP pools), the trick with host access won't work alone anymore as the dnsmasq and inspector need to change each other's (configuration) state. I guess that old patch needs to address this somehow.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the future as we move towards Kubernetes rearchitecting the services<br>
so they work better in containers is totally fine. If the services are<br>
that tightly coupled then why not just have one launch the other? </blockquote><div><br></div><div>That's my point of view as well. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Then they could live in the single container and have a common launch point.<br></blockquote><div><br></div><div>What I'd like to achieve with the supervisord inside of the shared container as, besides other things, inspector and dnsmasq have to start/fail together in the HA and spine-leaf-support case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Seems fine to me, but certainly isn't a requirement to get these up and<br>
running in the current architecture.<br></blockquote><div><br></div><div>But if addressed right now would save some effort in the future while, as a bonus, getting us the cool features sooner.</div><div><br></div><div>Would you mind testing the containerised undercloud with the inspector dnsmasq PXE filter patch chain[1] applied?</div><div><br></div><div><br></div><div>Thanks,</div><div>milan</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/q/topic:rebasing_filter+(status:open+OR+status:merged)">https://review.openstack.org/#/q/topic:rebasing_filter+(status:open+OR+status:merged)</a> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> Also would allow us to get rid of iptables and better encapsulate the<br>
> inspector services.<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>