Open Stack

út 17. 10. 2017 v 17:14 odesílatel Dan Prince <dprince at redhat.com> napsal:

> On Tue, 2017-10-17 at 11:46 +0000, milanisko k wrote:
> >
> > How about the shared container? Wouldn't it be better not have to
> > rely on t-h-t especially if we're "scheduling" (and probably
> > configuring) the services as a single logical entity?
>
> The containers architecture for Pike and Queens is very much oriented
> around preserving the way we deployed the services already on
> baremetal... but moving them into containers. So for Ironic inspector

we had 2 services (2 systemd scripts) both living in separate
> containers. Do the the shared nature of this architecture with regards
> to network and host access this works fine.
>

Unless new features, such as  the inspector support for routed/relayed
DHCP/PXE traffic (or spine&leaf network topology), come  into the question.
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.


> In the future as we move towards Kubernetes rearchitecting the services
> so they work better in containers is totally fine. If the services are
> that tightly coupled then why not just have one launch the other?


That's my point of view as well.

Then they could live in the single container and have a common launch point.
>

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.


> Seems fine to me, but certainly isn't a requirement to get these up and
> running in the current architecture.
>

But if addressed right now would save some effort in the future while, as a
bonus, getting us the cool features sooner.

Would you mind testing the containerised undercloud with the inspector
dnsmasq PXE filter patch chain[1] applied?


Thanks,
milan

[1]
https://review.openstack.org/#/q/topic:rebasing_filter+(status:open+OR+status:merged)



>
>
> > Also would allow us to get rid of iptables and better encapsulate the
> > inspector services.
>
> __________________________________________________________________________
> 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/20171018/d43b13ac/attachment.html>