Option 5:

If the implementation works good, but its just a confusing ui, you could always 
change the code so it filters out the floating-ip ports from view. Make them a 
pure implementation detail that a user never sees.

Kevin
________________________________
From: Salvatore Orlando [sorla...@nicira.com]
Sent: Tuesday, January 14, 2014 3:50 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] About ports backing floating IPs


TL;DR;
I have been looking back at the API and found out that it's a bit weird how 
floating IPs are mapped to ports. This might or might not be an issue, and 
several things can be done about it.
The rest of this post is a boring description of the problem and a possibly 
even more boring list of potential solutions.

Floating IPs are backed by ports on the external network where they are 
implemented; while there are good reason for doing so, this has some seemingly 
weird side effects, which are usually not visible to tenants as only admins are 
allowed (by default) to view the ports backing the floating IPs.

Assigning an external port to a floating IP is an easy way for ensuring the IP 
address used for the floating IP is then not reused for other allocation 
purposes on the external network; indeed admin users might start VMs on 
external networks as well. Conceptually, it is also an example of port-level 
insertion for a network service (DNAT/SNAT).

However these are the tricky aspects:
- IP Address changes: The API allows IP address updates for a floating IP port. 
However as it might be expected, the IP of the floating IP entities does not 
change, as well as the actual floating IP implemented in the backend (l3 agent 
or whatever the plugin uses).
- operational status: It is always down at least for plugins based on OVS/LB 
agents. This is because there is no actual VIF backing a floating IP, so there 
is nothing to wire.
- admin status: updating it just has no effect at all
- Security groups and  allowed address pairs: The API allows for updating them, 
but it is not clear whether something actually happens in the backend, and I'm 
even not entirely sure this makes sense at all.

Why these things happen, whether it's intended behaviour, and whether it's the 
right behaviour it's debatable.

>From my perspective, this leads to inconsistent state, as:
- the address reported in the floating IP entity might differ from the one on 
the port backing the floating IP
- operational status is wrongly represented as down
- expectations concerning operations on the port are not met (eg: admin status 
update)
And I reckon state inconsistencies should always be avoided.

Considering the situation described above, there are few possible options.

1- don't do anything, since the port backing the floating IP is hidden from the 
tenant.
This might be ok provided that a compelling reason for ignoring entities not 
visible to tenants is provided.
However it has to be noted that Neutron authZ logic, which is based on 
openstack.common would allow deployers to change that (*)

2- remove the need for a floating IP to be backed from a port
While this might seem simple, this has non-trivial implications as IPAM logic 
would need to become aware of floating IPs, and should  be discussed further.

3- leverage policy-based APIs, and transform floating IPs in a "remote access 
policy"
In this way the floating IP will become a policy to apply to a port; it will be 
easier to solve conflicts with security policies and it will be possible to 
just use IPs (or addressing policies) configured on the port.
However, this will be hardly backward compatible, and its feasibility depends 
on the outcome of the more general discussions on policy-based APIs for neutron.

4- Document the current behaviour
This is something which is probably worth doing anyway until a solution is 
agreed upon

Summarising, since all the 'technical' options sounds not feasible for the 
upcoming Icehouse release, it seems worth at least documenting the current 
behaviour, and start a discussion on whether we should do something about this 
and, if yes, what.

Regards and apologies for the long post,
Salvatore

(*) As an interesting corollary, the flexibility of making authZ policies 
super-configurable causes the API to be non-portable. However, this is a 
subject for a different discussion.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to