[openstack-dev] [Nova][Neutron] API inconsistencies with security groups

Christopher Yeoh cbkyeoh at gmail.com
Sun Apr 6 13:06:32 UTC 2014


On Sat, Apr 5, 2014 at 10:17 PM, Joshua Hesketh <
joshua.hesketh at 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.hesketh at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140406/4d80802b/attachment.html>


More information about the OpenStack-dev mailing list