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