Re: [openstack-dev] [Nova][Neutron] API inconsistencies with security groups
On Sun, Apr 6, 2014 at 6:06 AM, Christopher Yeoh cbky...@gmail.com wrote: On Sat, Apr 5, 2014 at 10:17 PM, Joshua Hesketh joshua.hesk...@rackspace.com wrote: Hi Chris, Thanks for your input. On 4/5/14 9:56 PM, Christopher Yeoh wrote: On Sat, 5 Apr 2014 15:16:33 +1100 Joshua Hesketh joshua.hesk...@rackspace.com wrote: I'm moving a conversation that has begun on a review to this mailing list as it is perhaps systematic of a larger issue regarding API compatibility (specifically between neutron and nova-networking). Unfortunately these are areas I don't have much experience with so I'm hoping to gain some clarity here. There is a bug in nova where launching an instance with a given security group is case-insensitive for nova-networks but case-sensitive for neutron. This highlights inconsistencies but I also think this is a legitimate bug[0]. Specifically the 'nova boot' command accepts the incorrectly cased security- group but the instance enters an error state as it has been unable to boot it. There is an inherent mistake here where the initial check approves the security-group name but when it comes time to assign the security group (at the scheduler level) it fails. I think this should be fixed but then the nova CLI behaves differently with different tasks. For example, `nova secgroup-add-rule` is case sensitive. So in reality it is unclear if security groups should, or should not, be case sensitive. The API implies that they should not. The CLI has methods where some are and some are not. I've addressed the initial bug as a patch to the neutron driver[1] and also amended the case-sensitive lookup in the python-novaclient[2] but both reviews are being held up by this issue. I guess the questions are: - are people aware of this inconsistency? - is there some documentation on the inconsistencies? - is a fix of this nature considered an API compatibility break? - and what are the expectations (in terms of case-sensitivity)? I don't know the history behind making security group names case insensitive for nova-network, but without that knowledge it seems a little odd to me. The Nova API is in general case sensitive - with the exception of when you supply types - eg True/False, Enabled/Disabled. If someone thinks there's a good reason for having it case insensitive then I'd like to hear what that is. But otherwise in an ideal world I think they should be case sensitive. Working with what we have however, I think it would also be bad if using the neutron API directly security group were case sensitive but talking to it via Nova it was case insensitive. Put this down as one of the risks of doing proxying type work in Nova. I think the proposed patches are backwards incompatible API changes. I agree that changing the python-novaclient[2] is new functionality and perhaps more controversial, but it is not directly related to an API change. The change I proposed to nova[1] stops the scheduler from getting stuck when it tries to launch an instance with an already accepted security group. Perhaps the fix here should be that the nova API never accepted the security group to begin with. However, that would be an API change. The change I've proposed at the moment stops instances from entering an error state, but it doesn't do anything to help with the inconsistencies. So if Nova can detect earlier on in the process that an instance launch is definitely going to fail because the security group is invalid then I think its ok to return an error to the user earlier rather than return success and have it fail later on anyway. So this changes the behavior for nova-network users. I don't really see any easy way out of this one, besides thorough documentation of the issue. That's likely true. However I would appreciate reviews on 77347 with the above in mind. I might be misunderstanding exactly what is going on here, but I'll comment directly on the 77347. Regards, Chris ___ 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] [Nova][Neutron] API inconsistencies with security groups
On Sat, Apr 5, 2014 at 10:17 PM, Joshua Hesketh joshua.hesk...@rackspace.com wrote: Hi Chris, Thanks for your input. On 4/5/14 9:56 PM, Christopher Yeoh wrote: On Sat, 5 Apr 2014 15:16:33 +1100 Joshua Hesketh joshua.hesk...@rackspace.com wrote: I'm moving a conversation that has begun on a review to this mailing list as it is perhaps systematic of a larger issue regarding API compatibility (specifically between neutron and nova-networking). Unfortunately these are areas I don't have much experience with so I'm hoping to gain some clarity here. There is a bug in nova where launching an instance with a given security group is case-insensitive for nova-networks but case-sensitive for neutron. This highlights inconsistencies but I also think this is a legitimate bug[0]. Specifically the 'nova boot' command accepts the incorrectly cased security- group but the instance enters an error state as it has been unable to boot it. There is an inherent mistake here where the initial check approves the security-group name but when it comes time to assign the security group (at the scheduler level) it fails. I think this should be fixed but then the nova CLI behaves differently with different tasks. For example, `nova secgroup-add-rule` is case sensitive. So in reality it is unclear if security groups should, or should not, be case sensitive. The API implies that they should not. The CLI has methods where some are and some are not. I've addressed the initial bug as a patch to the neutron driver[1] and also amended the case-sensitive lookup in the python-novaclient[2] but both reviews are being held up by this issue. I guess the questions are: - are people aware of this inconsistency? - is there some documentation on the inconsistencies? - is a fix of this nature considered an API compatibility break? - and what are the expectations (in terms of case-sensitivity)? I don't know the history behind making security group names case insensitive for nova-network, but without that knowledge it seems a little odd to me. The Nova API is in general case sensitive - with the exception of when you supply types - eg True/False, Enabled/Disabled. If someone thinks there's a good reason for having it case insensitive then I'd like to hear what that is. But otherwise in an ideal world I think they should be case sensitive. Working with what we have however, I think it would also be bad if using the neutron API directly security group were case sensitive but talking to it via Nova it was case insensitive. Put this down as one of the risks of doing proxying type work in Nova. I think the proposed patches are backwards incompatible API changes. I agree that changing the python-novaclient[2] is new functionality and perhaps more controversial, but it is not directly related to an API change. The change I proposed to nova[1] stops the scheduler from getting stuck when it tries to launch an instance with an already accepted security group. Perhaps the fix here should be that the nova API never accepted the security group to begin with. However, that would be an API change. The change I've proposed at the moment stops instances from entering an error state, but it doesn't do anything to help with the inconsistencies. So if Nova can detect earlier on in the process that an instance launch is definitely going to fail because the security group is invalid then I think its ok to return an error to the user earlier rather than return success and have it fail later on anyway. That's likely true. However I would appreciate reviews on 77347 with the above in mind. I might be misunderstanding exactly what is going on here, but I'll comment directly on the 77347. Regards, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] API inconsistencies with security groups
On Sat, 5 Apr 2014 15:16:33 +1100 Joshua Hesketh joshua.hesk...@rackspace.com wrote: I'm moving a conversation that has begun on a review to this mailing list as it is perhaps systematic of a larger issue regarding API compatibility (specifically between neutron and nova-networking). Unfortunately these are areas I don't have much experience with so I'm hoping to gain some clarity here. There is a bug in nova where launching an instance with a given security group is case-insensitive for nova-networks but case-sensitive for neutron. This highlights inconsistencies but I also think this is a legitimate bug[0]. Specifically the 'nova boot' command accepts the incorrectly cased security- group but the instance enters an error state as it has been unable to boot it. There is an inherent mistake here where the initial check approves the security-group name but when it comes time to assign the security group (at the scheduler level) it fails. I think this should be fixed but then the nova CLI behaves differently with different tasks. For example, `nova secgroup-add-rule` is case sensitive. So in reality it is unclear if security groups should, or should not, be case sensitive. The API implies that they should not. The CLI has methods where some are and some are not. I've addressed the initial bug as a patch to the neutron driver[1] and also amended the case-sensitive lookup in the python-novaclient[2] but both reviews are being held up by this issue. I guess the questions are: - are people aware of this inconsistency? - is there some documentation on the inconsistencies? - is a fix of this nature considered an API compatibility break? - and what are the expectations (in terms of case-sensitivity)? I don't know the history behind making security group names case insensitive for nova-network, but without that knowledge it seems a little odd to me. The Nova API is in general case sensitive - with the exception of when you supply types - eg True/False, Enabled/Disabled. If someone thinks there's a good reason for having it case insensitive then I'd like to hear what that is. But otherwise in an ideal world I think they should be case sensitive. Working with what we have however, I think it would also be bad if using the neutron API directly security group were case sensitive but talking to it via Nova it was case insensitive. Put this down as one of the risks of doing proxying type work in Nova. I think the proposed patches are backwards incompatible API changes. Short of a major version API rev in Neutron or Nova I suspect there's not a good solution. So perhaps for now documenting the issues around having neutron as the backend versus having nova-network has the backend is the best approach. Longer term I think I'd like to see the security group names always treated in a case sensitive manner. Chris. Cheers, Josh [0] https://launchpad.net/bugs/1286463 [1] https://review.openstack.org/#/c/77347/ [2] https://review.openstack.org/#/c/81688/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
