On Sat, Apr 5, 2014 at 10:17 PM, Joshua Hesketh < [email protected]> 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 <[email protected]> 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
