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? Maru _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
