Open Stack

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 <marun at redhat.com> wrote:
>
>
> On Dec 12, 2014, at 1:40 PM, 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.
>
> 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 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/a9afbe84/attachment.html>