Looking at all comments it seems that existing change is reasonable. I will update it with link to this thread.
Thanks! Regards, Ann Kamyshnikova On Sat, Dec 13, 2014 at 1:15 AM, Rochelle Grober <[email protected] > wrote: > > > > > Morgan Fainberg [mailto:[email protected]] *on* Friday, December > 12, 2014 2:01 PM wrote: > On Friday, December 12, 2014, Sean Dague <[email protected]> wrote: > > On 12/12/2014 01:05 PM, Maru Newby wrote: > > > > On Dec 11, 2014, at 2:27 PM, Sean Dague <[email protected]> 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 <[email protected]> wrote: > >>>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote: > >>>>>> > >>>>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau <[email protected]> wrote: > >>>>>> > >>>>>>> On Thu, Dec 11, 2014, Mark McClain <[email protected]> wrote: > >>>>>>>> > >>>>>>>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes <[email protected] > >>>>>>>>> <mailto:[email protected]>> 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. > > > > +1. > > > > More consistent and more usable is a good approach. The name uniqueness > has prior art in OpenStack - keystone keeps project names unique within a > domain (domain is the container), similar usernames can't be duplicated in > the same domain. It would be silly to auth with the user ID, likewise > unique names for the security group in the container (tenant) makes a lot > of sense from a UX Perspective. > > > > *[Rockyg] +1* > > *Especially when dealing with domain data that are managed by Humans, > human visible unique is important for understanding *and* efficiency. > Tenant security is expected to be managed by the tenant admin, not some > automated “robot admin” and as such needs to be clear , memorable and > seperable between instances. Unique names is the most straightforward (and > easiest to enforce) way do this for humans. Humans read differentiate > alphanumerics, so that should be the standard differentiator when humans > are expected to interact and reason about containers.* > > > > --Morgan > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
