Open Stack

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 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