----- Original Message -----
From: "Gary Kotton" <gkotton(a)redhat.com>
To: "Ofer Blaut" <oblaut(a)redhat.com>
Cc: rdo-list(a)redhat.com
Sent: Tuesday, June 18, 2013 9:11:57 AM
Subject: Re: [Rdo-list] Quantum and lack of connections
On 06/18/2013 09:02 AM, Ofer Blaut wrote:
>
> ----- Original Message -----
>> From: "Gary Kotton"<gkotton(a)redhat.com>
>> To: "Ofer Blaut"<oblaut(a)redhat.com>
>> Cc: rdo-list(a)redhat.com
>> Sent: Tuesday, June 18, 2013 8:58:05 AM
>> Subject: Re: [Rdo-list] Quantum and lack of connections
>>
>> On 06/18/2013 08:35 AM, Ofer Blaut wrote:
>>> Hi
>>>
>>> I wonder how can i configure quantum network /subnets/ports when L3/DHCP
>>> fails to connect to quantum server.
>> These are not related. The Quantum service enables the user to configure
>> the network configuration. The DHCP agent provides the IPAM
>> implementation and the L3 agent provides the floating IP and routing
>> support.
>>
>>> I expect that user will have CLI/API errors upon DHCP not connected , and
>>> new IPs will not be allocated
>> Yes, it would be nice if the user was able to know if there was a
>> problem, but it is not related at all to the Quantum API. In actual fact
>> the administrator is able to invoke the command: "quantum agent-list"
to
>> determine if there are any issues with the backiend implementation of
>> the Quantum API's. The administrator would in turn need to address the
>> issues.
> I don't expect user to check quantum agent-list all the time.
> In case DHCP/L3 fails , i think new commands should alert about it
> Can it be DHCP will miss it info about restart ?
Please differentiate between a user and an administrator. The user will
be able to configure ports, subnets and networks. The administrator is
responsible to ensure that the service is up and running. Anyone who
will be running a cloud service will need to ensure that they have
highly available and redundant dhcp and l3 agents. The way of monitoring
this is via the aforementioned command.
Thinking on it again, usually when there is
a bug in a service like malformed packet cause it to crash
both HA services might fail.
From system point of view, i think that when a DHCP/L3 service is
down, NEW config should NOT accepted , until service is back online
user should be alerted ad well as admin
Ofer
You are welcome to check out
http://docs.openstack.org/trunk/openstack-network/admin/content/ch_high_a...
>
> Ofer
>
>
>>> See errors attached
http://paste.openstack.org/show/38836/
>> From the traces it looks like the l3 agent has successfully connected
>> to the message broker. The DHCP agent is unable to connect to the
>> message broker. This may be during the boot process where it may take up
>> to a minute (this is due to the qpid timeouts)
>>
>>> Ofer
>>>
>>> _______________________________________________
>>> Rdo-list mailing list
>>> Rdo-list(a)redhat.com
>>>
https://www.redhat.com/mailman/listinfo/rdo-list
>>