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
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
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
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,
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:
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
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
7 matches
Mail list logo
