Open Stack

Cheers Phil,
It's not that I can't get to the instances - I'd assume it was an ARP issue
at that point - its the fact that Nova hasn't notified me that it has
assigned an IP address: see my additional note where I guessed an IP
address it would've assigned and I could access it... but management tools
were still blissfully unaware.
I used to have a working Diablo set up with pretty much this same set up
(this is under Essex RC1 / Ubuntu 12.04) and never had an issue.

This just looks like it has assigned the IP to the instance, but hasn't
notified the management underbelly of MySQL so any client tools
interrogating the instance doesn't see that nova has done this work already.

Kev

On 28 March 2012 13:04, Day, Phil <philip.day at hp.com> wrote:

> Are you sure that its Nova that is taking the time to associate the IP,
> and not an ARP issue in your network ?****
>
> ** **
>
> I’ve seen this behaviour when quickly reusing floating IP addresses – Nova
> does the assignment and sends out an unsolicited ARP response (assuming you
> have the “send_arp_for_ha” flag set) – this is in
> network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
> APR response can get dropped in the network, ad so if the switch doesn’t
> see this message and it already has a previous ARP mapping in its cache
> then it will continue to try and send traffic to the previous user of that
> address until the cache times out. ****
>
> ** **
>
> Note that some network failover systems send multiple requests to get more
> certainty around this (for example I’ve seen a VPN solution use 6 messages).
> ****
>
> ** **
>
> There are a couple of things you could try:****
>
> ** **
>
> **-          **Add a flag to be able to increase the number of
> arp_responses sent****
>
> **-          **Change the allocation of floating_ips so that instead of
> picking the first free one in the DB you pick the one which has been unused
> for the longest time (reduces the risk of reusing an address before the
> switch times out the entry in its cache).****
>
> ** **
>
> Phil****
>
> ** **
>
> *From:* openstack-bounces+philip.day=hp.com at lists.launchpad.net [mailto:
> openstack-bounces+philip.day=hp.com at lists.launchpad.net] *On Behalf Of *Kevin
> Jackson
> *Sent:* 28 March 2012 12:49
> *To:* openstack at lists.launchpad.net
> *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
> associate****
>
> ** **
>
> Hi all,****
>
> I've got the following set in my nova.conf:****
>
> ** **
>
> --auto_assign_floating_ip****
>
> ** **
>
> and I fire up an instance.****
>
> Everything works, a private IP is assigned... the instance is running...
> but it can take an inordinate amount of time (anywhere upwards of 2 mins,
> sometimes a lot longer) to associate a floating IP automatically.****
>
> ** **
>
> Anybody else experienced this?  Any clues on what I can do to troubleshoot
> this?  What is the condition when a Floating IP is assigned?  I've seen it
> assign Floating IPs very quickly when it is still Booting, not Active, say.
> ****
>
> Is it dependent on anything within the Instance itself?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Kev****
>
> --
> Kevin Jackson
> @itarchitectkev****
>



-- 
Kevin Jackson
@itarchitectkev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120328/0cfa511a/attachment.html>