Re: [openstack-dev] [Neutron] About ports backing floating IPs
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
Re: [openstack-dev] [Neutron] About ports backing floating IPs
Logically, the port is really an alias for the external port of the router, rather than being just detached. I'm not sure this adds much to the discussion, but clearly that's where its traffic goes and is terminated. From past experience (don't ask) weird things happen if you start creating your own ports on the external network. It's actually not a completely daft thing to do, if you're brave, but I don't think the IPAM for the network plays well with the IPAM for floating IPs. The answer is probably that floating IPs should be pulling out of the network's address pool, at the least. -- Ian. On 15 January 2014 00:50, Salvatore Orlando sorla...@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@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
Re: [openstack-dev] [Neutron] About ports backing floating IPs
I am also perplexed about the ports backing floating ips. when plugin is selected OVS or LB, the ip address belonging to a port backing that floating ip is really set on VIF of 'qg-' , what is the port real action? At 2014-01-15 07:50:36,Salvatore Orlando sorla...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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
Re: [openstack-dev] [Neutron] About ports backing floating IPs
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 sorla...@nicira.comwrote: 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
Re: [openstack-dev] [Neutron] About ports backing floating IPs
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
