So I think this is something we really should get agreement on across the open stack API first before flipping back and forth on a case by case basis. <br><br>Personally I think we should be using uuids for uniqueness and leave any extra restrictions to a ui layer if really required.  If we try to have name uniqueness then  "test " should be considered the same as " test" as " test " and it introduces all sorts of slightly different combos that look the same except under very close comparison. Add unicode for extra fun.<br><br>Chris<br><div class="gmail_quote">On Tue, 16 Dec 2014 at 7:24 am, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Dec 15, 2014, at 9:13 AM, Assaf Muller <<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>> wrote:<br>
<br>
><br>
><br>
> ----- Original Message -----<br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA512<br>
>><br>
>> I was (rightfully) asked to share my comments on the matter that I<br>
>> left in gerrit here. See below.<br>
>><br>
>> On 12/12/14 22:40, Sean Dague wrote:<br>
>>> On 12/12/2014 01:05 PM, Maru Newby wrote:<br>
>>>><br>
>>>> On Dec 11, 2014, at 2:27 PM, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>> wrote:<br>
>>>><br>
>>>>> On 12/11/2014 04:16 PM, Jay Pipes wrote:<br>
>>>>>> On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:<br>
>>>>>>> On Dec 11, 2014, at 1:04 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>><br>
>>>>>>> wrote:<br>
>>>>>>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:<br>
>>>>>>>>><br>
>>>>>>>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau<br>
>>>>>>>>> <<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>>> On Thu, Dec 11, 2014, Mark McClain <mark@mcclain.xyz><br>
>>>>>>>>>> wrote:<br>
>>>>>>>>>>><br>
>>>>>>>>>>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes<br>
>>>>>>>>>>>> <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>><br>
>>>>>>>>>>>> wrote:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> I'm generally in favor of making name attributes<br>
>>>>>>>>>>>> opaque, utf-8 strings that are entirely<br>
>>>>>>>>>>>> user-defined and have no constraints on them. I<br>
>>>>>>>>>>>> consider the name to be just a tag that the user<br>
>>>>>>>>>>>> places on some resource. It is the resource's ID<br>
>>>>>>>>>>>> that is unique.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> I do realize that Nova takes a different approach<br>
>>>>>>>>>>>> to *some* resources, including the security group<br>
>>>>>>>>>>>> name.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> End of the day, it's probably just a personal<br>
>>>>>>>>>>>> preference whether names should be unique to a<br>
>>>>>>>>>>>> tenant/user or not.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Maru had asked me my opinion on whether names<br>
>>>>>>>>>>>> should be unique and I answered my personal<br>
>>>>>>>>>>>> opinion that no, they should not be, and if<br>
>>>>>>>>>>>> Neutron needed to ensure that there was one and<br>
>>>>>>>>>>>> only one default security group for a tenant,<br>
>>>>>>>>>>>> that a way to accomplish such a thing in a<br>
>>>>>>>>>>>> race-free way, without use of SELECT FOR UPDATE,<br>
>>>>>>>>>>>> was to use the approach I put into the pastebin<br>
>>>>>>>>>>>> on the review above.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> I agree with Jay.  We should not care about how a<br>
>>>>>>>>>>> user names the resource. There other ways to<br>
>>>>>>>>>>> prevent this race and Jay’s suggestion is a good<br>
>>>>>>>>>>> one.<br>
>>>>>>>>>><br>
>>>>>>>>>> However we should open a bug against Horizon because<br>
>>>>>>>>>> the user experience there is terrible with duplicate<br>
>>>>>>>>>> security group names.<br>
>>>>>>>>><br>
>>>>>>>>> The reason security group names are unique is that the<br>
>>>>>>>>> ec2 api supports source rule specifications by<br>
>>>>>>>>> tenant_id (user_id in amazon) and name, so not<br>
>>>>>>>>> enforcing uniqueness means that invocation in the ec2<br>
>>>>>>>>> api will either fail or be non-deterministic in some<br>
>>>>>>>>> way.<br>
>>>>>>>><br>
>>>>>>>> So we should couple our API evolution to EC2 API then?<br>
>>>>>>>><br>
>>>>>>>> -jay<br>
>>>>>>><br>
>>>>>>> No I was just pointing out the historical reason for<br>
>>>>>>> uniqueness, and hopefully encouraging someone to find the<br>
>>>>>>> best behavior for the ec2 api if we are going to keep the<br>
>>>>>>> incompatibility there. Also I personally feel the ux is<br>
>>>>>>> better with unique names, but it is only a slight<br>
>>>>>>> preference.<br>
>>>>>><br>
>>>>>> Sorry for snapping, you made a fair point.<br>
>>>>><br>
>>>>> Yeh, honestly, I agree with Vish. I do feel that the UX of<br>
>>>>> that constraint is useful. Otherwise you get into having to<br>
>>>>> show people UUIDs in a lot more places. While those are good<br>
>>>>> for consistency, they are kind of terrible to show to people.<br>
>>>><br>
>>>> While there is a good case for the UX of unique names - it also<br>
>>>> makes orchestration via tools like puppet a heck of a lot simpler<br>
>>>> - the fact is that most OpenStack resources do not require unique<br>
>>>> names.  That being the case, why would we want security groups to<br>
>>>> deviate from this convention?<br>
>>><br>
>>> Maybe the other ones are the broken ones?<br>
>>><br>
>>> Honestly, any sanely usable system makes names unique inside a<br>
>>> container. Like files in a directory.<br>
>><br>
>> Correct. Or take git: it does not use hashes to identify objects, right?<br>
>><br>
>>> In this case the tenant is the container, which makes sense.<br>
>>><br>
>>> It is one of many places that OpenStack is not consistent. But I'd<br>
>>> rather make things consistent and more usable than consistent and<br>
>>> less.<br>
>><br>
>> Are we only proposing to make security group name unique? I assume<br>
>> that, since that's what we currently have in review. The change would<br>
>> make API *more* inconsistent, not less, since other objects still use<br>
>> uuid for identification.<br>
>><br>
>> You may say that we should move *all* neutron objects to the new<br>
>> identification system by name. But what's the real benefit?<br>
>><br>
>> If there are problems in UX (client, horizon, ...), we should fix the<br>
>> view and not data models used. If we decide we want users to avoid<br>
>> using objects with the same names, fine, let's add warnings in UI<br>
>> (probably with an option to disable it so that we don't push the<br>
>> validation into their throats).<br>
>><br>
>> Finally, I have concern about us changing user visible object<br>
>> attributes like names during db migrations, as it's proposed in the<br>
>> patch discussed here. I think such behaviour can be quite unexpected<br>
>> for some users, if not breaking their workflow and/or scripts.<br>
>><br>
>> My belief is that responsible upstream does not apply ad-hoc changes<br>
>> to API to fix a race condition that is easily solvable in other ways<br>
>> (see Assaf's proposal to introduce a new DefaultSecurityGroups table<br>
>> in patchset 12 comments).<br>
>><br>
><br>
> As usual you explain yourself better than I can... I think my main<br>
> original objection to the patch is that it feels like an accidental<br>
> API change to fix a bug. If you want unique naming:<br>
> 1) We need to be consistent across different resources<br>
> 2) It needs to be in a dedicate change, and perhaps blueprint<br>
><br>
> Since there's conceivable alternative solutions to the bug that aren't<br>
> substantially more costly or complicated, I don't see why we would pursue<br>
> the proposed approach.<br>
<br>
<br>
+1<br>
<br>
Regardless of the merits of security groups having unique names, I don’t think it is a change that should be slipped in as part of a bugfix.  If we want to see this kind of API-modifying change introduced in Neutron (or any other OpenStack project), there is a process that needs to be followed.<br>
<br>
<br>
<br>
Maru<br>
<br>
<br>
><br>
>> As for the whole object identification scheme change, for this to<br>
>> work, it probably needs a spec and a long discussion on any possible<br>
>> complications (and benefits) when applying a change like that.<br>
>><br>
>> For reference and convenience of readers, leaving the link to the<br>
>> patch below: <a href="https://review.openstack.org/#/c/135006/" target="_blank">https://review.openstack.org/#<u></u>/c/135006/</a><br>
>><br>
>><br>
>><br>
>>><br>
>>> -Sean<br>
>>><br>
>> -----BEGIN PGP SIGNATURE-----<br>
>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
>><br>
>> iQEcBAEBCgAGBQJUjxI1AAoJEC5aWa<u></u>UY1u579M8H/RC+M7/<u></u>9YYDClWRjhQLBNqEq<br>
>> 0pMxURZi8lTyDmi+<u></u>cXA7wq1QzgOwUqWnJnOMYzq8nt9wLh<u></u>8cgasjU5YXZokrqDLw<br>
>> zEu/<u></u>a1Cd9Alp4iGYQ6upw94BptGrMvk+<u></u>XwTedMX9zMLf0od1k8Gzp5xYH/<u></u>GXInN3<br>
>> E+wje40Huia0MmLu4i2GMr/<u></u>13gD2aYhMeGxZtDMcxQsF0DBh0gy8O<u></u>M9pfKgIiXVM<br>
>> T65nFbXUY1/<u></u>PuAdzYwMto5leuWZH03YIddXlzkQbc<u></u>ZoH4PGgNEE3eKl1ctQSMGoo<br>
>> bz3l522VimQvVnP/<u></u>XiM6xBjFqsnPM5Tc7Ylu942l+<u></u>NfpfcAM5QB6Ihvw5kQI0uw=<br>
>> =gIsu<br>
>> -----END PGP SIGNATURE-----<br>
>><br>
>> ______________________________<u></u>_________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
>><br>
><br>
> ______________________________<u></u>_________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>