Open Stack

On Nov 21, 2012, at 7:40 AM, Lars Kellogg-Stedman <lars at 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