Open Stack

On 13 February 2018 at 14:02, Brent Eagles <beagles at redhat.com> wrote:

> Hi,
>
> The neutron agents are implemented in such a way that key functionality is
> implemented in terms of haproxy, dnsmasq, keepalived and radvd
> configuration. The agents manage instances of these services but, by
> design, the parent is the top-most (pid 1).
>
> On baremetal this has the advantage that, while control plane changes
> cannot be made while the agents are not available, the configuration at the
> time the agents were stopped will work (for example, VMs that are restarted
> can request their IPs, etc). In short, the dataplane is not affected by
> shutting down the agents.
>
> In the TripleO containerized version of these agents, the supporting
> processes (haproxy, dnsmasq, etc.) are run within the agent's container so
> when the container is stopped, the supporting processes are also stopped.
> That is, the behavior with the current containers is significantly
> different than on baremetal and stopping/restarting containers effectively
> breaks the dataplane. At the moment this is being considered a blocker and
> unless we can find a resolution, we may need to recommend running the L3,
> DHCP and metadata agents on baremetal.
>
>
There's quite a bit to unpack here: are you suggesting that running these
services in HA configuration doesn't help either with the data plane being
gone after a stop/restart? Ultimately this boils down to where the state is
persisted, and while certain agents rely on namespaces and processes whose
ephemeral nature is hard to persist, enough could be done to allow for a
non-disruptive bumping of the afore mentioned services.

Thanks,
Armando


> Cheers,
>
> Brent Eagles
> Daniel Alvarez
>
> __________________________________________________________________________
> 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/20180213/133f9e16/attachment.html>