Open Stack

This is based on the behavior of elastic ips in amazon where a call to associate an ip with a new instance will simply move it.

Vish

On Nov 6, 2012, at 4:53 PM, Stef T <stef at ummon.com> wrote:

> Hello Everyone,
>     So, before I start making code changes to nova-network, I have to ask, why does the nova-network first disassociate the floating-ip before associating it ? Surely, if the floating-ip is associated with another instance it shouldn't jst be disassociated blindly ?
> 
>     I refer to line 477 of nova/network/manager.py (the associate_floating_ip method) and specifically this;
> 
>         # make sure project owns this floating ip (allocated)
>         self._floating_ip_owned_by_project(context, floating_ip)
> 
>         # disassociate any already associated
>         orig_instance_uuid = None
>         if floating_ip['fixed_ip_id']:
>             # find previously associated instance
>             fixed_ip = self.db.fixed_ip_get(context,
>                                             floating_ip['fixed_ip_id'])
>             orig_instance_uuid = fixed_ip['instance_uuid']
> 
>             self.disassociate_floating_ip(context, floating_address)
> 
>     Now, I can see two solutions, in the case that this is 'correct'. One is to create a method called 're-associate'. The other idea is to only allow disassocation to happen if there is a 'force' flag (or some such). 
> 
>     In the case of more than one operator, it's REALLY easy to step on each others toes. This is even before I get onto the whole notion of malicious intent.
> 
>     Am I reading this wrong ? I am open to being an idiot :)
> 
>     Regards
>     S.
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121106/db692f24/attachment.html>