[Rdo-list] Quantum and lack of connections

[Ofer Blaut]

----- Original Message -----
> From: "Gary Kotton" <gkotton at redhat.com>
> To: "Ofer Blaut" <oblaut at redhat.com>
> Cc: rdo-list at 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 at redhat.com>
> >> To: "Ofer Blaut"<oblaut at redhat.com>
> >> Cc: rdo-list at 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_avail.html
> 
> >
> > 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 at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/rdo-list
> >>
> 
>