The L3 agent monitors the metadata proxies it spawns and restarts them automatically. You should be using an external tool to restart the metadata *agent* in case that crashes.
On Sun, Dec 13, 2015 at 7:49 AM, Gary Kotton <gkot...@vmware.com> wrote: > > > From: Eugene Nikanorov <enikano...@mirantis.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Sunday, December 13, 2015 at 12:09 PM > To: OpenStack List <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] neutron metadata-agent HA > > It is as 'single' as active L3 router that is handling traffic at current > point of time. > > [Gary] But if the l3 agent is up and running and the metadataproxy is not > then all of the instances using that agent will not be able to get their > metadata. > > On Sun, Dec 13, 2015 at 11:13 AM, Gary Kotton <gkot...@vmware.com> wrote: >> >> >> >> >> >> >> On 12/12/15, 10:44 PM, "Assaf Muller" <amul...@redhat.com> wrote: >> >> >The neutron metadata agent is stateless. It takes requests from the >> >metadata proxies running in the router namespaces and moves the >> >requests on to the nova server. If you're using HA routers, start the >> >neutron-metadata-agent on every machine the L3 agent runs, and just >> >make sure that the metadata-agent is restarted in case it crashes and >> >you're done. >> >> So does this mean that it could be the single point of failure? >> >> >Nothing else you need to do. >> > >> >On Fri, Dec 11, 2015 at 3:24 PM, Fabrizio Soppelsa >> ><fsoppe...@mirantis.com> wrote: >> >> >> >> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo <alvise.dor...@pd.infn.it> >> >> wrote: >> >> >> >> So my question is: is there any progress on this topic ? is there a way >> >> (something like a cronjob script) to make the metadata-agent redundant >> >> without involving the clustering software Pacemaker/Corosync ? >> >> >> >> >> >> Reason for such a dirty solution instead of rely onto pacemaker? >> >> >> >> I’m not aware of such initiatives - just checked the blueprints in >> >> Neutron >> >> and I found no relevant. I can suggest to file a proposal to the >> >> correspondent launchpad page, by elaborating your idea. >> >> >> >> F. >> >> >> >> >> >> __________________________________________________________________________ >> >> 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 >> __________________________________________________________________________ >> 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 > __________________________________________________________________________ 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
