Open Stack

On Sun, Apr 6, 2014 at 6:06 AM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:

> 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.
>

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 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/20140415/f877d2e6/attachment.html>