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