út 17. 10. 2017 v 17:14 odesílatel Dan Prince <dpri...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
