openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #18810
Re: FIXED IT! Re: Floating ip addresses take forever to display
On Nov 21, 2012, at 7:40 AM, Lars Kellogg-Stedman <lars@xxxxxxxxxxxxxxxx> 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
Follow ups
References