<stab in the dark> Have you kept an eye on the mysql table itself, rather than relying on the cli tools / dashboard that may very well cache the data? </stab in the dark>
Thanks, Kiall On Wed, Mar 28, 2012 at 1:58 PM, Kevin Jackson <ke...@linuxservices.co.uk>wrote: > 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....@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....@lists.launchpad.net [mailto: >> openstack-bounces+philip.day=hp....@lists.launchpad.net] *On Behalf Of *Kevin >> Jackson >> *Sent:* 28 March 2012 12:49 >> *To:* openstack@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 > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
