Hi Armando, Sort of... but what happens when the second one dies? If one DHCP agent dies, I need to be able to start a new DHCP agent on another host and take over from it. As far as I can tell right now, when one DHCP agent dies, another doesn't take up the slack.
I have the same problem wit L3 agents by the way, that's next on my list -- Noel On Tue, Oct 21, 2014 at 12:52 PM, Armando M. <arma...@gmail.com> wrote: > As far as I can tell when you specify: > > dhcp_agents_per_network = X > 1 > > The server binds the network to all the agents (up to X), which means that > you have multiple instances of dnsmasq serving dhcp requests at the same > time. If one agent dies, there is no fail-over needed per se, as the other > agent will continue to server dhcp requests unaffected. > > For instance, in my env I have dhcp_agents_per_network=2, so If I create > a network, and list the agents serving the network I will see the following: > > neutron dhcp-agent-list-hosting-net test > > +--------------------------------------+--------+----------------+-------+ > > | id | host | admin_state_up | alive | > > +--------------------------------------+--------+----------------+-------+ > > | 6dd09649-5e24-403b-9654-7aa0f69f04fb | host1 | True | :-) | > > | 7d47721a-2725-45f8-b7c4-2731cfabdb48 | host2 | True | :-) | > > +--------------------------------------+--------+----------------+-------+ > > Isn't that what you're after? > > Cheers, > Armando > > On 21 October 2014 22:26, Noel Burton-Krahn <n...@pistoncloud.com> wrote: > >> We currently have a mechanism for restarting the DHCP agent on another >> node, but we'd like the new agent to take over all the old networks of the >> failed dhcp instance. Right now, since dhcp agents are distinguished by >> host, and the host has to match the host of the ovs agent, and the ovs >> agent's host has to be unique per node, the new dhcp agent is registered as >> a completely new agent and doesn't take over the failed agent's networks. >> I'm looking for a way to give the new agent the same roles as the previous >> one. >> >> -- >> Noel >> >> >> On Tue, Oct 21, 2014 at 12:12 AM, Kevin Benton <blak...@gmail.com> wrote: >> >>> No, unfortunately when the DHCP agent dies there isn't automatic >>> rescheduling at the moment. >>> >>> On Mon, Oct 20, 2014 at 11:56 PM, Noel Burton-Krahn < >>> n...@pistoncloud.com> wrote: >>> >>>> Thanks for the pointer! >>>> >>>> I like how the first google hit for this is: >>>> >>>> Add details on dhcp_agents_per_network option for DHCP agent HA >>>> https://bugs.launchpad.net/openstack-manuals/+bug/1370934 >>>> >>>> :) Seems reasonable to set dhcp_agents_per_network > 1. What happens >>>> when a DHCP agent dies? Does the scheduler automatically bind another >>>> agent to that network? >>>> >>>> Cheers, >>>> -- >>>> Noel >>>> >>>> >>>> >>>> On Mon, Oct 20, 2014 at 9:03 PM, Jian Wen <wenjia...@gmail.com> wrote: >>>> >>>>> See dhcp_agents_per_network in neutron.conf. >>>>> >>>>> https://bugs.launchpad.net/neutron/+bug/1174132 >>>>> >>>>> 2014-10-21 6:47 GMT+08:00 Noel Burton-Krahn <n...@pistoncloud.com>: >>>>> >>>>>> I've been working on failover for dhcp and L3 agents. I see that in >>>>>> [1], multiple dhcp agents can host the same network. However, it looks >>>>>> like I have to manually assign networks to multiple dhcp agents, which >>>>>> won't work. Shouldn't multiple dhcp agents automatically fail over? >>>>>> >>>>>> [1] >>>>>> http://docs.openstack.org/trunk/config-reference/content/multi_agent_demo_configuration.html >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best, >>>>> >>>>> Jian >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Kevin Benton >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev