On Nov 22, 2012, at 1:47 AM, Thierry Carrez wrote:
> Alan Pevec wrote:
>> 2012/11/22 Lars Kellogg-Stedman :
>>> 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 mov
2012/11/22 Thierry Carrez :
> 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
>
Alan Pevec wrote:
> 2012/11/22 Lars Kellogg-Stedman :
>> 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
2012/11/22 Lars Kellogg-Stedman :
> 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.or
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
On Nov 21, 2012, at 7:40 AM, Lars Kellogg-Stedman 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.net
> 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, instan
7 matches
Mail list logo
