Open Stack

----- Original Message -----
> From: "Brent Eagles" <beagles at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Monday, December 23, 2013 10:48:50 PM
> Subject: Re: [openstack-dev] [neutron][qa] test_network_basic_ops and the "FloatingIPChecker" control point
> 
> Salvatore Orlando wrote:
> > Before starting this post I confess I did not read with the
> > required level
> > of attention all this thread, so I apologise for any repetition.
> >
> > I just wanted to point out that floating IPs in neutron are created
> > asynchronously when using the l3 agent, and I think this is clear
> > to
> > everybody.
> > So when the create floating IP call returns, this does not mean the
> > floating IP has actually been wired, ie: IP configured on
> > qg-interface and
> > SNAT/DNAT rules added.
> >
> > Unfortunately, neutron lacks a concept of operational status for a
> > floating
> > IP which would tell clients, including nova (it acts as a client
> > wrt nova
> > api), when a floating IP is ready to be used. I started work in
> > this
> > direction, but it has been suspended now for a week. If anybody
> > wants to
> > take over and deems this a reasonable thing to do, it will be
> > great.
> 
> Unless somebody picks it up before I get from the break, I'd like to
> discuss this further with you.
> 
> > I think neutron tests checking connectivity might return more
> > meaningful
> > failure data if they would gather the status of the various
> > components
> > which might impact connectivity.
> > These are:
> > - The floating IP
> > - The router internal interface
> > - The VIF port
> > - The DHCP agent
I wrote something addressing at least some of these points: https://review.openstack.org/#/c/55146/
> 
> I agree wholeheartedly. In fact, I think if we are going to rely on
> timeouts for pass/fail we need to do more for post-mortem details.
> 
> > Collecting info about the latter is very important but a bit
> > trickier. I
> > discussed with Sean and Maru that it would be great for a starter,
> > grep the
> > console log to check whether the instance obtained an IP.
> > Other things to consider would be:
> > - adding an operational status to a subnet, which would express
> > whether the
> > DHCP agent is in sync with that subnet (this information won't make
> > sense
> > for subnets with dhcp disabled)
> > - working on a 'debug' administrative API which could return, for
> > instance,
> > for each DHCP agent the list of configured networks and leases.
> 
> Interesting!
> 
> > Regarding timeouts, I think it's fair for tempest to define a
> > timeout and
> > ask that everything from VM boot to Floating IP wiring completes
> > within
> > that timeout.
> >
> > Regards,
> > Salvatore
> 
> I would agree. It would be impossible to have reasonable automated
> testing otherwise.
> 
> Cheers,
> 
> Brent
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>