Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
Alan Pevec wrote: 2012/11/22 Lars Kellogg-Stedman l...@seas.harvard.edu: Any chance we can get it fixed in Essex, too? Or has this release been abandoned? I'm not clear on what the maintenance schedule looks like as the steamroller of progress moves forward. Current stable branch policy is documented in http://wiki.openstack.org/StableBranch tld;r openstack-stable-maint team actively backports fixes to stable/folsom branch. Separate openstack-diablo-maint and openstack-essex-maint teams exist for older branches, but they accept serious issues e.g. security fixes only. Note that diablo/essex-maint teams are 1-2 members only, so if you have resources I'm sure they'd welcome any help they can get. It's more a question of how disruptive the patch is vs. how critical the bug is. Given how annoying this bug is, it would be good to at least assess the disruption factor of a backport. Did we identify the bug number (or commit id) of the Folsom fix, so that we can open an Essex task for it ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
2012/11/22 Thierry Carrez thie...@openstack.org: It's more a question of how disruptive the patch is vs. how critical the bug is. Given how annoying this bug is, it would be good to at least assess the disruption factor of a backport. Did we identify the bug number (or commit id) of the Folsom fix, so that we can open an Essex task for it ? That's exactly what I'm saying, you need someone to do all of this (asses risk/benefit, find master fix and backport it, eventually make a new stable release) and currently only Dave Walker signed up for this work: https://launchpad.net/~openstack-essex-maint/+members Cheers, Alan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
On Nov 22, 2012, at 1:47 AM, Thierry Carrez thie...@openstack.org wrote: Alan Pevec wrote: 2012/11/22 Lars Kellogg-Stedman l...@seas.harvard.edu: Any chance we can get it fixed in Essex, too? Or has this release been abandoned? I'm not clear on what the maintenance schedule looks like as the steamroller of progress moves forward. Current stable branch policy is documented in http://wiki.openstack.org/StableBranch tld;r openstack-stable-maint team actively backports fixes to stable/folsom branch. Separate openstack-diablo-maint and openstack-essex-maint teams exist for older branches, but they accept serious issues e.g. security fixes only. Note that diablo/essex-maint teams are 1-2 members only, so if you have resources I'm sure they'd welcome any help they can get. It's more a question of how disruptive the patch is vs. how critical the bug is. Given how annoying this bug is, it would be good to at least assess the disruption factor of a backport. Backporting the whole refresh_cache would be very painful, but I think this could be done with a one line addition to update the cache at the end of network_api.allocate_for_instance which doesn't seem very disruptive. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] FIXED IT! Re: Floating ip addresses take forever to display
compute.api.associate_floating_ip. Do automatically assigned addresses follow the same process as manually assigned ones? The answer is NO! - compute.manager._allocate_network calls: network_info = self.network_api.allocate_for_instance( context, instance, vpn=is_vpn, requested_networks=requested_networks) ...but as far as I can tell, this code path never calls network.api.invalidate_instance_cache. Adding a call to self.network_api.invalidate_instance_cache immediately after the above call completely resolves this problem. The actual ip assignment happens in network.manager.FloatingIP.allocate_for_instance, which does this: if FLAGS.auto_assign_floating_ip: # allocate a floating ip floating_address = self.allocate_floating_ip(context, project_id) # set auto_assigned column to true for the floating ip self.db.floating_ip_set_auto_assigned(context, floating_address) # get the first fixed address belonging to the instance fixed_ips = nw_info.fixed_ips() fixed_address = fixed_ips[0]['address'] # associate the floating ip to fixed_ip self.associate_floating_ip(context, floating_address, fixed_address, affect_auto_assigned=True) Nothing in manager.py ever calls invalidate_instance_cache. -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
On Nov 21, 2012, at 7:40 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote: compute.api.associate_floating_ip. Do automatically assigned addresses follow the same process as manually assigned ones? The answer is NO! - compute.manager._allocate_network calls: network_info = self.network_api.allocate_for_instance( context, instance, vpn=is_vpn, requested_networks=requested_networks) ...but as far as I can tell, this code path never calls network.api.invalidate_instance_cache. Adding a call to self.network_api.invalidate_instance_cache immediately after the above call completely resolves this problem. The actual ip assignment happens in network.manager.FloatingIP.allocate_for_instance, which does this: if FLAGS.auto_assign_floating_ip: # allocate a floating ip floating_address = self.allocate_floating_ip(context, project_id) # set auto_assigned column to true for the floating ip self.db.floating_ip_set_auto_assigned(context, floating_address) # get the first fixed address belonging to the instance fixed_ips = nw_info.fixed_ips() fixed_address = fixed_ips[0]['address'] # associate the floating ip to fixed_ip self.associate_floating_ip(context, floating_address, fixed_address, affect_auto_assigned=True) Nothing in manager.py ever calls invalidate_instance_cache. This appears to be essex. Invalidate instance cache should ideally be called on the network_api side before returning from allocate_for_instance. If you look at folsom, you'll see there is a decorator for this purpose called @refresh_cache Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
On Wed, Nov 21, 2012 at 09:12:36AM -0800, Vishvananda Ishaya wrote: This appears to be essex. That's correct. be called on the network_api side before returning from allocate_for_instance. I agree. If you look at folsom, you'll see there is a decorator for this purpose called @refresh_cache Any chance we can get it fixed in Essex, too? Or has this release been abandoned? I'm not clear on what the maintenance schedule looks like as the steamroller of progress moves forward. -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FIXED IT! Re: Floating ip addresses take forever to display
2012/11/22 Lars Kellogg-Stedman l...@seas.harvard.edu: Any chance we can get it fixed in Essex, too? Or has this release been abandoned? I'm not clear on what the maintenance schedule looks like as the steamroller of progress moves forward. Current stable branch policy is documented in http://wiki.openstack.org/StableBranch tld;r openstack-stable-maint team actively backports fixes to stable/folsom branch. Separate openstack-diablo-maint and openstack-essex-maint teams exist for older branches, but they accept serious issues e.g. security fixes only. Note that diablo/essex-maint teams are 1-2 members only, so if you have resources I'm sure they'd welcome any help they can get. Cheers, Alan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
