On Dec 12, 2014, at 1:40 PM, Sean Dague <s...@dague.net> wrote: > On 12/12/2014 01:05 PM, Maru Newby wrote: >> >> On Dec 11, 2014, at 2:27 PM, Sean Dague <s...@dague.net> wrote: >> >>> On 12/11/2014 04:16 PM, Jay Pipes wrote: >>>> On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote: >>>>> On Dec 11, 2014, at 1:04 PM, Jay Pipes <jaypi...@gmail.com> wrote: >>>>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote: >>>>>>> >>>>>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau <ges...@cisco.com> wrote: >>>>>>> >>>>>>>> On Thu, Dec 11, 2014, Mark McClain <m...@mcclain.xyz> wrote: >>>>>>>>> >>>>>>>>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes <jaypi...@gmail.com >>>>>>>>>> <mailto:jaypi...@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> I'm generally in favor of making name attributes opaque, utf-8 >>>>>>>>>> strings that >>>>>>>>>> are entirely user-defined and have no constraints on them. I >>>>>>>>>> consider the >>>>>>>>>> name to be just a tag that the user places on some resource. It >>>>>>>>>> is the >>>>>>>>>> resource's ID that is unique. >>>>>>>>>> >>>>>>>>>> I do realize that Nova takes a different approach to *some* >>>>>>>>>> resources, >>>>>>>>>> including the security group name. >>>>>>>>>> >>>>>>>>>> End of the day, it's probably just a personal preference whether >>>>>>>>>> names >>>>>>>>>> should be unique to a tenant/user or not. >>>>>>>>>> >>>>>>>>>> Maru had asked me my opinion on whether names should be unique and I >>>>>>>>>> answered my personal opinion that no, they should not be, and if >>>>>>>>>> Neutron >>>>>>>>>> needed to ensure that there was one and only one default security >>>>>>>>>> group for >>>>>>>>>> a tenant, that a way to accomplish such a thing in a race-free >>>>>>>>>> way, without >>>>>>>>>> use of SELECT FOR UPDATE, was to use the approach I put into the >>>>>>>>>> pastebin on >>>>>>>>>> the review above. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I agree with Jay. We should not care about how a user names the >>>>>>>>> resource. >>>>>>>>> There other ways to prevent this race and Jay’s suggestion is a >>>>>>>>> good one. >>>>>>>> >>>>>>>> However we should open a bug against Horizon because the user >>>>>>>> experience there >>>>>>>> is terrible with duplicate security group names. >>>>>>> >>>>>>> The reason security group names are unique is that the ec2 api >>>>>>> supports source >>>>>>> rule specifications by tenant_id (user_id in amazon) and name, so >>>>>>> not enforcing >>>>>>> uniqueness means that invocation in the ec2 api will either fail or be >>>>>>> non-deterministic in some way. >>>>>> >>>>>> So we should couple our API evolution to EC2 API then? >>>>>> >>>>>> -jay >>>>> >>>>> No I was just pointing out the historical reason for uniqueness, and >>>>> hopefully >>>>> encouraging someone to find the best behavior for the ec2 api if we >>>>> are going >>>>> to keep the incompatibility there. Also I personally feel the ux is >>>>> better >>>>> with unique names, but it is only a slight preference. >>>> >>>> Sorry for snapping, you made a fair point. >>> >>> Yeh, honestly, I agree with Vish. I do feel that the UX of that >>> constraint is useful. Otherwise you get into having to show people UUIDs >>> in a lot more places. While those are good for consistency, they are >>> kind of terrible to show to people. >> >> While there is a good case for the UX of unique names - it also makes >> orchestration via tools like puppet a heck of a lot simpler - the fact is >> that most OpenStack resources do not require unique names. That being the >> case, why would we want security groups to deviate from this convention? > > Maybe the other ones are the broken ones? > > Honestly, any sanely usable system makes names unique inside a > container. Like files in a directory. In this case the tenant is the > container, which makes sense. > > It is one of many places that OpenStack is not consistent. But I'd > rather make things consistent and more usable than consistent and less.
You might prefer less consistency for the sake of usability, but for me, consistency is a large enough factor in usability that allowing seemingly arbitrary deviation doesn’t seem like a huge win. Regardless, I’d like to see us came to decisions on API usability on an OpenStack-wide basis, so the API working group is probably where this discussion should continue. Maru _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
