If you want rescheduling, you need a script to do it. There is a feature for that behavior in Juno, but only for the L3 agent. [1]
1. http://docs.openstack.org/trunk/config-reference/content/networking-options-l3_agent.html On Tue, Oct 21, 2014 at 4:27 PM, Noel Burton-Krahn <[email protected]> wrote: > 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. <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected]> 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 <[email protected]>: >>>>>> >>>>>>> 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 >>>>>>> [email protected] >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best, >>>>>> >>>>>> Jian >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> [email protected] >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Kevin Benton >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
