Created attachment 768679 [details] log Description of problem: I created 10 instances and tried to associate a floating ip to each one without waiting for each request to get success message. (so move between each instance -> more -> associate ip) it appears that some of the instances will get a floating ip and others will not. Version-Release number of selected component (if applicable): python-django-horizon-2013.1.2-1.el6ost.noarch How reproducible: 100% Steps to Reproduce: 1. launch 10 instance 2. move between each one -> more -> associate ip without waiting for each request to get a success alert 3. Actual results: some of the instance do not get an ip. Expected results: all instances should get an ip. Additional info: log Please note that the errors in horizon log for ip limit is after 10 ips and not related to this issue.
Is this using nova-network or quantum? Does waiting a few minutes and refreshing the page after associating the IP give the correct result? (I notice sometimes IPs are not associated instantly, particularly when using Quantum). Would it be possible to fix the test environment so that the "Unauthorised" errors do no appear in the logs? The noise makes it difficult to understand what's happening. The fact that the quota limit of 10 is hit suggests that all 10 Floating IPs were eventually assigned.
(In reply to Julie Pichon from comment #1) > Is this using nova-network or quantum? this is nova network > > Does waiting a few minutes and refreshing the page after associating the IP > give the correct result? (I notice sometimes IPs are not associated > instantly, particularly when using Quantum). > the problem is not the refresh its the request load. if I do it one at a time everything is greate but if you send the requests fast than at the end some will be sent and some will not. > Would it be possible to fix the test environment so that the "Unauthorised" > errors do no appear in the logs? The noise makes it difficult to understand > what's happening. The fact that the quota limit of 10 is hit suggests that > all 10 Floating IPs were eventually assigned. I am working with a packstack install in which the logs are not in debug mode. can simply grep -v ERROR so that you can see what you like without the ERORR threads. the quota errors are not related as I wrote when I opened the bug. they were part of a different test that I ran before.
Associating an IP causes the page to reload in order to display the new IP associated with the instance in the table. I think that what happened is that the button was clicked just as the page finished reloading from a previous request, therefore the new request didn't have time to go through. It can be not very obvious if the page is slow to reload. When I tried to reproduce this, I can see in the Horizon logs that only X floating IP requests were sent to Nova, where X matches the number of instances with an IP associated in the end. At this time there is no "One Click Associate" when using Neutron, so we're less likely to see this. I'm not sure what recommendation there is to avoid this otherwise. I don't think the impact is very high, because the instances that were missed can be assigned a floating IP on a 2nd try. The workaround when this happens is to click "Associate Floating IP" again when the page is reloaded.
Liz, Would you have ideas on how to handle this more gracefully from a user experience perspective? I chatted with a few people who suggested greying out/blocking every other button on the page when performing an action such as one-click associate IP, to wait until the action is completed and the page has reloaded but it seems somewhat unfriendly to me, since there are so many buttons - and not *all* of the following actions fail. I'm not sure which trade-off is best.
Hi Julie, I agree that greying out all other buttons on the page while the action is performing is a bit unfriendly to the user. I think that greying out the "Associate Floating IP" action might make sense in this case. Perhaps also adding some sort of visual feedback in the table to let the user know that this is currently working might help, too. My thoughts here would be a spinning icon with a message stating "Associating Floating IP" if it fits and if it's technically possible. This would at least let the use know that something is happening as they are waiting. Also it would be a good hint as to why they might not be able to select this action again on any other instance at that time. Thoughts on this approach? Thanks, Liz
Hi Dafna, Could you try to reproduce this on a recent version of Horizon and, if this still occurs, also report the bug upstream? Thank you.
sorry Julie, I do not have a nova network setup any more and with neutron you need to manually assign the ip's (unlike nova where you just assign -> save). perhaps Yogev can help if they still have setups installed with nova, setting need info on him
I wasn't able to reproduce the bug, all of the instances got the a floating IP.
Thanks for the feedback Yogev. I'll close the bug for now then.