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....@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 [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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev