Open Stack

Agreed Kevin.

This will make the inconsistencies disappear from the API. On the other
hand, this would be a bit like sweeping the dust under the carpet as those
inconsistencies will still exist in the data model.

Yong, the issue with arbitrary changes to device_id and device_owner is
real and I think you were already tackling it. I would like this discussion
to stay focused on ports for floating IPs. The first goal is to understand
if it actually is a problem or not.

Salvatore


On 14 January 2014 20:19, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

>  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 [sorlando at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140115/3a2a2260/attachment.html>