Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron
2015-07-15 22:57 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 7/15/2015 3:24 AM, Alex Xu wrote: 2015-07-15 5:14 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com: On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies , where it’s stated that Nova shouldn’t be proxying API calls. That said, Matt Riedemann brings up the point that this breaks the case where Neutron is installed and we want to be more graceful, rather than just raising an exception. Here are some options: 1. fail - (the code in the patch above) 2. proxy to neutron for floating ips and security groups - that's what the original change was doing back in havana 3. return -1 or something for floatingips/security groups to indicate that we don't know, you have to get those from neutron Does anybody have an opinion on which option we should do regarding API proxies in this case? Thanks, Cale Rath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer the proxy option, despite that we don't want to do more proxies to other services, it's the least of all evils here in my opinion. I don't think we can do #1, that breaks anyone using those APIs and is using Neutron, so it's a non-starter. agree #3 is an API change in semantics which would at least be a microversion and is kind of clunky. agree too~ For #2 we at least have the nova.network.base_api which we didn't have in Havana when I was originally working on this, that would abstract the neutron-specific cruft out of the nova-api code. The calls to neutron were pretty simple from what I remember - we could just resurrect the old patch: https://review.openstack.org/#/c/43822/ +1, but looks like this need new microversion also. It means after 2.x version, this api value is valid for neutron, before 2.x version, don't trust this api... I'm not exactly clear on why we couldn't implement this as a bug fix for v2.0? I guess because of the standard reason we give for all microversions which is discoverability. yes...It is the standard reason I guess in the v2.0 case we could just log the warning (option 4). It's not great, but at least it's a thing that an operator could find if they are using v2.0 and expecting proper quotas/limits values for security groups and floating IPs when using neutron but talking to the nova-api. This info is more important for API user, so API doc is enough? Another option is #4, we mark the bug as won't fix and we log a warning if neutron is configured saying some of the resources aren't going to be correct, use the neutron API to get information for quotas on security groups, floating IPs, etc. That's also kind of gross IMO, but it's an option. if we plan to deprecate network proxy api in no longer future, this is easy option. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron
2015-07-15 5:14 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies , where it’s stated that Nova shouldn’t be proxying API calls. That said, Matt Riedemann brings up the point that this breaks the case where Neutron is installed and we want to be more graceful, rather than just raising an exception. Here are some options: 1. fail - (the code in the patch above) 2. proxy to neutron for floating ips and security groups - that's what the original change was doing back in havana 3. return -1 or something for floatingips/security groups to indicate that we don't know, you have to get those from neutron Does anybody have an opinion on which option we should do regarding API proxies in this case? Thanks, Cale Rath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer the proxy option, despite that we don't want to do more proxies to other services, it's the least of all evils here in my opinion. I don't think we can do #1, that breaks anyone using those APIs and is using Neutron, so it's a non-starter. agree #3 is an API change in semantics which would at least be a microversion and is kind of clunky. agree too~ For #2 we at least have the nova.network.base_api which we didn't have in Havana when I was originally working on this, that would abstract the neutron-specific cruft out of the nova-api code. The calls to neutron were pretty simple from what I remember - we could just resurrect the old patch: https://review.openstack.org/#/c/43822/ +1, but looks like this need new microversion also. It means after 2.x version, this api value is valid for neutron, before 2.x version, don't trust this api... Another option is #4, we mark the bug as won't fix and we log a warning if neutron is configured saying some of the resources aren't going to be correct, use the neutron API to get information for quotas on security groups, floating IPs, etc. That's also kind of gross IMO, but it's an option. if we plan to deprecate network proxy api in no longer future, this is easy option. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron
Some comments inline. Salvatore On 15 July 2015 at 10:24, Alex Xu sou...@gmail.com wrote: 2015-07-15 5:14 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies , where it’s stated that Nova shouldn’t be proxying API calls. That said, Matt Riedemann brings up the point that this breaks the case where Neutron is installed and we want to be more graceful, rather than just raising an exception. Here are some options: 1. fail - (the code in the patch above) 2. proxy to neutron for floating ips and security groups - that's what the original change was doing back in havana 3. return -1 or something for floatingips/security groups to indicate that we don't know, you have to get those from neutron Does anybody have an opinion on which option we should do regarding API proxies in this case? Thanks, Cale Rath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer the proxy option, despite that we don't want to do more proxies to other services, it's the least of all evils here in my opinion. I don't think we can do #1, that breaks anyone using those APIs and is using Neutron, so it's a non-starter. agree #3 is an API change in semantics which would at least be a microversion and is kind of clunky. agree too~ Also it overlaps with Neutron semantics of returning -1 for unlimited and it could be misinterpreted. For #2 we at least have the nova.network.base_api which we didn't have in Havana when I was originally working on this, that would abstract the neutron-specific cruft out of the nova-api code. The calls to neutron were pretty simple from what I remember - we could just resurrect the old patch: https://review.openstack.org/#/c/43822/ +1, but looks like this need new microversion also. It means after 2.x version, this api value is valid for neutron, before 2.x version, don't trust this api... This is correct, and makes sense in my opinion. Still, I agree more that the final goal should be to stop proxying this calls. #2 is in my opinion a good strategy for transitioning to #1. I am not sure whether it is acceptable to just document that retrieving limits in Nova for resources managed by other projects is deprecated and will not be allowed anymore in M or N. Another option is #4, we mark the bug as won't fix and we log a warning if neutron is configured saying some of the resources aren't going to be correct, use the neutron API to get information for quotas on security groups, floating IPs, etc. That's also kind of gross IMO, but it's an option. if we plan to deprecate network proxy api in no longer future, this is easy option. I am not sure this is a good option. The warning in this case should be returned to the user making the limits request; logging it just tells the operator somebody has retrieved limits using a proxy. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron
On 7/15/2015 4:22 AM, Salvatore Orlando wrote: Some comments inline. Salvatore On 15 July 2015 at 10:24, Alex Xu sou...@gmail.com mailto:sou...@gmail.com wrote: 2015-07-15 5:14 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com: On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies, where it’s stated that Nova shouldn’t be proxying API calls. That said, Matt Riedemann brings up the point that this breaks the case where Neutron is installed and we want to be more graceful, rather than just raising an exception. Here are some options: 1. fail - (the code in the patch above) 2. proxy to neutron for floating ips and security groups - that's what the original change was doing back in havana 3. return -1 or something for floatingips/security groups to indicate that we don't know, you have to get those from neutron Does anybody have an opinion on which option we should do regarding API proxies in this case? Thanks, Cale Rath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer the proxy option, despite that we don't want to do more proxies to other services, it's the least of all evils here in my opinion. I don't think we can do #1, that breaks anyone using those APIs and is using Neutron, so it's a non-starter. agree #3 is an API change in semantics which would at least be a microversion and is kind of clunky. agree too~ Also it overlaps with Neutron semantics of returning -1 for unlimited and it could be misinterpreted. Yeah, good point on the -1 for unlimited quota, that's how it's treated in nova also. For #2 we at least have the nova.network.base_api which we didn't have in Havana when I was originally working on this, that would abstract the neutron-specific cruft out of the nova-api code. The calls to neutron were pretty simple from what I remember - we could just resurrect the old patch: https://review.openstack.org/#/c/43822/ +1, but looks like this need new microversion also. It means after 2.x version, this api value is valid for neutron, before 2.x version, don't trust this api... This is correct, and makes sense in my opinion. Still, I agree more that the final goal should be to stop proxying this calls. #2 is in my opinion a good strategy for transitioning to #1. I am not sure whether it is acceptable to just document that retrieving limits in Nova for resources managed by other projects is deprecated and will not be allowed anymore in M or N. Another option is #4, we mark the bug as won't fix and we log a warning if neutron is configured saying some of the resources aren't going to be correct, use the neutron API to get information for quotas on security groups, floating IPs, etc. That's also kind of gross IMO, but it's an option. if we plan to deprecate network proxy api in no longer future, this is easy option. I am not sure this is a good option. The warning in this case should be returned to the user making the limits request; logging it just tells the operator somebody has retrieved limits using a proxy. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron
On 7/15/2015 3:24 AM, Alex Xu wrote: 2015-07-15 5:14 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com: On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies, where it’s stated that Nova shouldn’t be proxying API calls. That said, Matt Riedemann brings up the point that this breaks the case where Neutron is installed and we want to be more graceful, rather than just raising an exception. Here are some options: 1. fail - (the code in the patch above) 2. proxy to neutron for floating ips and security groups - that's what the original change was doing back in havana 3. return -1 or something for floatingips/security groups to indicate that we don't know, you have to get those from neutron Does anybody have an opinion on which option we should do regarding API proxies in this case? Thanks, Cale Rath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer the proxy option, despite that we don't want to do more proxies to other services, it's the least of all evils here in my opinion. I don't think we can do #1, that breaks anyone using those APIs and is using Neutron, so it's a non-starter. agree #3 is an API change in semantics which would at least be a microversion and is kind of clunky. agree too~ For #2 we at least have the nova.network.base_api which we didn't have in Havana when I was originally working on this, that would abstract the neutron-specific cruft out of the nova-api code. The calls to neutron were pretty simple from what I remember - we could just resurrect the old patch: https://review.openstack.org/#/c/43822/ +1, but looks like this need new microversion also. It means after 2.x version, this api value is valid for neutron, before 2.x version, don't trust this api... I'm not exactly clear on why we couldn't implement this as a bug fix for v2.0? I guess because of the standard reason we give for all microversions which is discoverability. I guess in the v2.0 case we could just log the warning (option 4). It's not great, but at least it's a thing that an operator could find if they are using v2.0 and expecting proper quotas/limits values for security groups and floating IPs when using neutron but talking to the nova-api. Another option is #4, we mark the bug as won't fix and we log a warning if neutron is configured saying some of the resources aren't going to be correct, use the neutron API to get information for quotas on security groups, floating IPs, etc. That's also kind of gross IMO, but it's an option. if we plan to deprecate network proxy api in no longer future, this is easy option. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron
On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies, where it’s stated that Nova shouldn’t be proxying API calls. That said, Matt Riedemann brings up the point that this breaks the case where Neutron is installed and we want to be more graceful, rather than just raising an exception. Here are some options: 1. fail - (the code in the patch above) 2. proxy to neutron for floating ips and security groups - that's what the original change was doing back in havana 3. return -1 or something for floatingips/security groups to indicate that we don't know, you have to get those from neutron Does anybody have an opinion on which option we should do regarding API proxies in this case? Thanks, Cale Rath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I prefer the proxy option, despite that we don't want to do more proxies to other services, it's the least of all evils here in my opinion. I don't think we can do #1, that breaks anyone using those APIs and is using Neutron, so it's a non-starter. #3 is an API change in semantics which would at least be a microversion and is kind of clunky. For #2 we at least have the nova.network.base_api which we didn't have in Havana when I was originally working on this, that would abstract the neutron-specific cruft out of the nova-api code. The calls to neutron were pretty simple from what I remember - we could just resurrect the old patch: https://review.openstack.org/#/c/43822/ Another option is #4, we mark the bug as won't fix and we log a warning if neutron is configured saying some of the resources aren't going to be correct, use the neutron API to get information for quotas on security groups, floating IPs, etc. That's also kind of gross IMO, but it's an option. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
