Open Stack

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 <noel at pistoncloud.com>
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. <armamig at 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 <noel at 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 <blak111 at 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 <
>>>> noel at 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 <wenjianhn at 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 <noel at 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 at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best,
>>>>>>
>>>>>> Jian
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Kevin Benton
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141022/59615741/attachment.html>