Open Stack

for all ports:
user can change the device_id and device owner easily, it will cause mess
in particularly for system ports, such as router interface and gateway
ports, dhcp ports etc.

dhcp port:
there is not point of updating its security groups, and I don't know the
effect when we update its Ip addresses from API too.

this applies to other system ports.



On Wed, Jan 15, 2014 at 7:50 AM, Salvatore Orlando <sorlando at nicira.com>wrote:

> 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/809a3173/attachment.html>