Open Stack

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 <rochelle.grober at huawei.com
> wrote:

>
>
>
>
> Morgan Fainberg [mailto:morgan.fainberg at gmail.com] *on* Friday, December
> 12, 2014 2:01 PM wrote:
> On Friday, December 12, 2014, Sean Dague <sean at dague.net> wrote:
>
> On 12/12/2014 01:05 PM, Maru Newby wrote:
> >
> > On Dec 11, 2014, at 2:27 PM, Sean Dague <sean at 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 <jaypipes at gmail.com> wrote:
> >>>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> >>>>>>
> >>>>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau <gessau at cisco.com> wrote:
> >>>>>>
> >>>>>>> On Thu, Dec 11, 2014, Mark McClain <mark at mcclain.xyz> wrote:
> >>>>>>>>
> >>>>>>>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes <jaypipes at gmail.com
> >>>>>>>>> <mailto:jaypipes at 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.
>
>
>
> +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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141215/cc80ef2f/attachment.html>