Open Stack

On 12/12/2014 05:00 PM, Morgan Fainberg wrote:
> On Friday, December 12, 2014, Sean Dague <sean at dague.net
> <mailto: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
>     <javascript:;>> 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
>     <javascript:;>> 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
>     <javascript:;>> 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 <javascript:;>
>      >>>>>>>>> <mailto:jaypipes at gmail.com <javascript:;>>> 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.

Sounds like Maru and I are pretty heavily in the minority on this one, 
and you all make good points about UX and consistency with other pieces 
of the OpenStack APIs.

Maru, I'm backing off here and will support putting a unique constraint 
on the security group name and project_id field.

Best,
-jay