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