I think the point made is that the behaviour is currently inconsistent and not user friendly. Regardless of that, I would like to point that technically this kind of change is backward incompatible and so it should not be simply approved by popular acclamation.
I will seek input from the API WG in the next meeting. Salvatore On 15 December 2014 at 20:39, Maru Newby <ma...@redhat.com> wrote: > > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev