Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Mathieu Gagné]

On 2014-12-16 12:07 AM, Christopher Yeoh wrote:

So I think this is something we really should get agreement on across
the open stack API first before flipping back and forth on a case by
case basis.

Personally I think we should be using uuids for uniqueness and leave any
extra restrictions to a ui layer if really required. If we try to have
name uniqueness then "test " should be considered the same as " test" as
" test " and it introduces all sorts of slightly different combos that
look the same except under very close comparison. Add unicode for extra fun.



Leaving such uniqueness validation to the UI layer is a *huge no-no*.

The problem I had in production occurred in a non-UI system.

Please consider making it great for all users, not just the one 
(Horizon) provided by OpenStack.


--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Christopher Yeoh]

So I think this is something we really should get agreement on across the
open stack API first before flipping back and forth on a case by case
basis.

Personally I think we should be using uuids for uniqueness and leave any
extra restrictions to a ui layer if really required. If we try to have name
uniqueness then "test " should be considered the same as " test" as " test
" and it introduces all sorts of slightly different combos that look the
same except under very close comparison. Add unicode for extra fun.

Chris
On Tue, 16 Dec 2014 at 7:24 am, Maru Newby  wrote:

>
> On Dec 15, 2014, at 9:13 AM, Assaf Muller  wrote:
>
> >
> >
> > - Original Message -
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> I was (rightfully) asked to share my comments on the matter that I
> >> left in gerrit here. See below.
> >>
> >> On 12/12/14 22:40, Sean Dague wrote:
> >>> On 12/12/2014 01:05 PM, Maru Newby wrote:
> 
>  On Dec 11, 2014, at 2:27 PM, Sean Dague  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 
> >>> wrote:
>  On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> >
> > On Dec 11, 2014, at 8:00 AM, Henry Gessau
> >  wrote:
> >
> >> On Thu, Dec 11, 2014, Mark McClain 
> >> wrote:
> >>>
>  On Dec 11, 2014, at 8:43 AM, Jay Pipes
>  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.
> >>
> >> Correct. Or take git: it does not use hashes to identify objects, right?
> >>
> >>> In this case the tenant is the container, which makes se

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Maru Newby]

On Dec 15, 2014, at 9:13 AM, Assaf Muller  wrote:

> 
> 
> - Original Message -
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> I was (rightfully) asked to share my comments on the matter that I
>> left in gerrit here. See below.
>> 
>> On 12/12/14 22:40, Sean Dague wrote:
>>> On 12/12/2014 01:05 PM, Maru Newby wrote:
 
 On Dec 11, 2014, at 2:27 PM, Sean Dague  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 
>>> wrote:
 On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> 
> On Dec 11, 2014, at 8:00 AM, Henry Gessau
>  wrote:
> 
>> On Thu, Dec 11, 2014, Mark McClain 
>> wrote:
>>> 
 On Dec 11, 2014, at 8:43 AM, Jay Pipes
 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.
>> 
>> Correct. Or take git: it does not use hashes to identify objects, right?
>> 
>>> 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.
>> 
>> Are we only proposing to make security group name unique? I assume
>> that, since that's what we currently have in review. The change would
>> make API *more* inconsistent, not less, since other objects still use
>> uuid for identification.
>> 
>> You may say that we should move *all* neutron objects to the new
>> identification system by name. But what's the real benefit?
>> 
>> If there are problems in UX (client, horizon, ...), we should fix the
>> view and not data models used. If we decide we want users to avoid
>> using objects with the same names, fine, let's add warnings in UI
>

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Salvatore Orlando]

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  wrote:
>
>
> On Dec 12, 2014, at 1:40 PM, Sean Dague  wrote:
>
> > On 12/12/2014 01:05 PM, Maru Newby wrote:
> >>
> >> On Dec 11, 2014, at 2:27 PM, Sean Dague  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  wrote:
> >> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> >>>
> >>> On Dec 11, 2014, at 8:00 AM, Henry Gessau 
> wrote:
> >>>
>  On Thu, Dec 11, 2014, Mark McClain  wrote:
> >
> >> On Dec 11, 2014, at 8:43 AM, Jay Pipes  >> > 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
>

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Maru Newby]

On Dec 12, 2014, at 1:40 PM, Sean Dague  wrote:

> On 12/12/2014 01:05 PM, Maru Newby wrote:
>> 
>> On Dec 11, 2014, at 2:27 PM, Sean Dague  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  wrote:
>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>>> 
>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:
>>> 
 On Thu, Dec 11, 2014, Mark McClain  wrote:
> 
>> On Dec 11, 2014, at 8:43 AM, Jay Pipes > > 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

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Assaf Muller]

- Original Message -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I was (rightfully) asked to share my comments on the matter that I
> left in gerrit here. See below.
> 
> On 12/12/14 22:40, Sean Dague wrote:
> > On 12/12/2014 01:05 PM, Maru Newby wrote:
> >> 
> >> On Dec 11, 2014, at 2:27 PM, Sean Dague  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 
> > wrote:
> >> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> >>> 
> >>> On Dec 11, 2014, at 8:00 AM, Henry Gessau
> >>>  wrote:
> >>> 
>  On Thu, Dec 11, 2014, Mark McClain 
>  wrote:
> > 
> >> On Dec 11, 2014, at 8:43 AM, Jay Pipes
> >> 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.
> 
> Correct. Or take git: it does not use hashes to identify objects, right?
> 
> > 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.
> 
> Are we only proposing to make security group name unique? I assume
> that, since that's what we currently have in review. The change would
> make API *more* inconsistent, not less, since other objects still use
> uuid for identification.
> 
> You may say that we should move *all* neutron objects to the new
> identification system by name. But what's the real benefit?
> 
> If there are problems in UX (client, horizon, ...), we should fix the
> view and not data models used. If we decide we want users to avoid
> using objects with the same names, fine, let's add warnings in UI
> (probably with an option to disable it so that we don't push the
> validation i

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I was (rightfully) asked to share my comments on the matter that I
left in gerrit here. See below.

On 12/12/14 22:40, Sean Dague wrote:
> On 12/12/2014 01:05 PM, Maru Newby wrote:
>> 
>> On Dec 11, 2014, at 2:27 PM, Sean Dague  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 
> wrote:
>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>>> 
>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau
>>>  wrote:
>>> 
 On Thu, Dec 11, 2014, Mark McClain 
 wrote:
> 
>> On Dec 11, 2014, at 8:43 AM, Jay Pipes
>> 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.

Correct. Or take git: it does not use hashes to identify objects, right?

> 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.

Are we only proposing to make security group name unique? I assume
that, since that's what we currently have in review. The change would
make API *more* inconsistent, not less, since other objects still use
uuid for identification.

You may say that we should move *all* neutron objects to the new
identification system by name. But what's the real benefit?

If there are problems in UX (client, horizon, ...), we should fix the
view and not data models used. If we decide we want users to avoid
using objects with the same names, fine, let's add warnings in UI
(probably with an option to disable it so that we don't push the
validation into their throats).

Finally, I have concern about us changing user visible object
attributes like names during db migrations, as it's proposed in the
patch discussed here. I think such behaviour can be quite unexpected
for some users, if not breaking their workfl

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Anna Kamyshnikova]

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  wrote:

>
>
>
>
> Morgan Fainberg [mailto:morgan.fainb...@gmail.com] *on* Friday, December
> 12, 2014 2:01 PM wrote:
> On Friday, December 12, 2014, Sean Dague  wrote:
>
> On 12/12/2014 01:05 PM, Maru Newby wrote:
> >
> > On Dec 11, 2014, at 2:27 PM, Sean Dague  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  wrote:
> > On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> >>
> >> On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:
> >>
> >>> On Thu, Dec 11, 2014, Mark McClain  wrote:
> 
> > On Dec 11, 2014, at 8:43 AM, Jay Pipes  > > 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 b

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Rochelle Grober]

Morgan Fainberg [mailto:morgan.fainb...@gmail.com] on Friday, December 12, 2014 
2:01 PM wrote:
On Friday, December 12, 2014, Sean Dague 
mailto:s...@dague.net>> wrote:
On 12/12/2014 01:05 PM, Maru Newby wrote:
>
> On Dec 11, 2014, at 2:27 PM, Sean Dague > 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 > 
 wrote:
> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>>
>> On Dec 11, 2014, at 8:00 AM, Henry Gessau 
>> > wrote:
>>
>>> On Thu, Dec 11, 2014, Mark McClain  wrote:

> On Dec 11, 2014, at 8:43 AM, Jay Pipes 
> 
> > 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@lists.openstack.

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Jay Pipes]

On 12/12/2014 05:00 PM, Morgan Fainberg wrote:

On Friday, December 12, 2014, Sean Dague mailto:s...@dague.net>> wrote:

On 12/12/2014 01:05 PM, Maru Newby wrote:
 >
 > On Dec 11, 2014, at 2:27 PM, Sean Dague > 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 > wrote:
 > On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
 >>
 >> On Dec 11, 2014, at 8:00 AM, Henry Gessau > wrote:
 >>
 >>> On Thu, Dec 11, 2014, Mark McClain  wrote:
 
 > On Dec 11, 2014, at 8:43 AM, Jay Pipes

 > > 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 na

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Morgan Fainberg]

On Friday, December 12, 2014, Sean Dague  wrote:

> On 12/12/2014 01:05 PM, Maru Newby wrote:
> >
> > On Dec 11, 2014, at 2:27 PM, Sean Dague >
> 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  > wrote:
> > On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> >>
> >> On Dec 11, 2014, at 8:00 AM, Henry Gessau  > wrote:
> >>
> >>> On Thu, Dec 11, 2014, Mark McClain  wrote:
> 
> > On Dec 11, 2014, at 8:43 AM, Jay Pipes  
> > > 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.

--Morgan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Mathieu Gagné]

On 2014-12-12 4:40 PM, Sean Dague wrote:


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.


+1

It makes as much sense as a filesystem accepting 2 files in the same 
folder with the same name but allows you to distinguish them by their 
inode number.


--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Sean Dague]

On 12/12/2014 01:05 PM, Maru Newby wrote:
> 
> On Dec 11, 2014, at 2:27 PM, Sean Dague  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  wrote:
> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>>
>> On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:
>>
>>> On Thu, Dec 11, 2014, Mark McClain  wrote:

> On Dec 11, 2014, at 8:43 AM, Jay Pipes  > 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.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Kevin Benton]

If we allow resource IDs to be set they will no longer be globally unique.
I'm not sure if this will impact anything directly right now, but it might
be something that impacts tools orchestrating multiple neutron deployments
(e.g. cascading, cells, etc).

On Fri, Dec 12, 2014 at 10:25 AM, Ivar Lazzaro 
wrote:

> In general, I agree with Jay about the opaqueness of the names. I see
> however good reasons for having user-defined unique attributes (see
>  Clint's point about idempotency).
> A middle ground here could be granting to the users the ability to specify
> the resource ID.
> A similar proposal was made some time ago by Eugene [0]
>
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046150.html
>
> On Thu, Dec 11, 2014 at 6:59 AM, Mark McClain  wrote:
>
>>
>> On Dec 11, 2014, at 8:43 AM, Jay Pipes  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.
>>
>> mark
>>
>>
>>
>> ___
>> 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
>
>


-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Ivar Lazzaro]

In general, I agree with Jay about the opaqueness of the names. I see
however good reasons for having user-defined unique attributes (see
 Clint's point about idempotency).
A middle ground here could be granting to the users the ability to specify
the resource ID.
A similar proposal was made some time ago by Eugene [0]


[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046150.html

On Thu, Dec 11, 2014 at 6:59 AM, Mark McClain  wrote:
>
>
> On Dec 11, 2014, at 8:43 AM, Jay Pipes  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.
>
> mark
>
>
>
> ___
> 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

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Maru Newby]

On Dec 11, 2014, at 2:27 PM, Sean Dague  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  wrote:
 On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
> 
> On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:
> 
>> On Thu, Dec 11, 2014, Mark McClain  wrote:
>>> 
 On Dec 11, 2014, at 8:43 AM, Jay Pipes >>> > 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?


Maru



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Anna Kamyshnikova]

Thanks everyone for sharing yours opinion! I will create a separate change
with another option that was suggested.

Yes, I'm currently working on this bug
https://bugs.launchpad.net/neutron/+bug/1194579.



On Fri, Dec 12, 2014 at 2:41 PM, Ihar Hrachyshka 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 12/12/14 00:05, Mathieu Gagné wrote:
> > We recently had an issue in production where a user had 2
> > "default" security groups (for reasons we have yet to identify).
>
> This is probably the result of the race condition that is discussed in
> the thread: https://bugs.launchpad.net/neutron/+bug/1194579
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
> iQEcBAEBCgAGBQJUitR/AAoJEC5aWaUY1u57VggIALzdTLHnO7Fr8gKlWPS7Uu+o
> Su9KV41td8Epzs3pNsGYkH2Kz4T5obAneCORUiZl7boBpAJcnMm3Jt9K8YnTCVUy
> t4AbfIxSrTD7drHf3HoMoNEDrSntdnpTHoGpG+idNpFjc0kjBjm81W3y14Gab0k5
> 5Mw/jV8mdnB6aRs5Zhari50/04X8SZeDpQNgBHL5kY40CZ+sUtS4C8OKfj7OEAuW
> LNmkHgDAtwewbNdluntbSdLGVjyl/F9s+21HoajqBcGNhH8ZHpAr4hphMbZv8lBY
> iAD2tztxvkacYaGduBFh6bewxVNGaUJBWmmc2xqHAXXbDP3d9aOk5q0wHK3SPQY=
> =TDwc
> -END PGP SIGNATURE-
>
> ___
> 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

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/12/14 00:05, Mathieu Gagné wrote:
> We recently had an issue in production where a user had 2
> "default" security groups (for reasons we have yet to identify).

This is probably the result of the race condition that is discussed in
the thread: https://bugs.launchpad.net/neutron/+bug/1194579
/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUitR/AAoJEC5aWaUY1u57VggIALzdTLHnO7Fr8gKlWPS7Uu+o
Su9KV41td8Epzs3pNsGYkH2Kz4T5obAneCORUiZl7boBpAJcnMm3Jt9K8YnTCVUy
t4AbfIxSrTD7drHf3HoMoNEDrSntdnpTHoGpG+idNpFjc0kjBjm81W3y14Gab0k5
5Mw/jV8mdnB6aRs5Zhari50/04X8SZeDpQNgBHL5kY40CZ+sUtS4C8OKfj7OEAuW
LNmkHgDAtwewbNdluntbSdLGVjyl/F9s+21HoajqBcGNhH8ZHpAr4hphMbZv8lBY
iAD2tztxvkacYaGduBFh6bewxVNGaUJBWmmc2xqHAXXbDP3d9aOk5q0wHK3SPQY=
=TDwc
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Cory Benfield]

On Thu, Dec 11, 2014 at 23:05:01, Mathieu Gagné wrote:
> When no security group is provided, Nova will default to the "default"
> security group. However due to the fact 2 security groups had the same
> name, nova-compute got confused, put the instance in ERROR state and
> logged this traceback [1]:
> 
>NoUniqueMatch: Multiple security groups found matching 'default'.
> Use
> an ID to be more specific.
> 

We've hit this in our automated testing in the past as well. Similarly, we have 
no idea how we managed to achieve this, but it's clearly something that the 
APIs allow you to do. That feels unwise.

> - the instance request should be blocked before it ends up on a compute
> node with nova-compute. It shouldn't be the job of nova-compute to
> find
> out issues about duplicated names. It should be the job of nova-api.
> Don't waste your time scheduling and spawning an instance that will
> never spawn with success.
> 
> - From an end user perspective, this means "nova boot" returns no error
> and it's only later that the user is informed of the confusion with
> security group names.
> 
> - Why does it have to crash with a traceback? IMO, traceback means "we
> didn't think about this use case, here is more information on how to
> find the source". As an operator, I don't care about the traceback if
> it's a known limitation of Nova/Neutron. Don't pollute my logs with
> "normal exceptions". (Log rationalization anyone?)

+1 to all of this.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Rochelle Grober]

First, I agree that it's much friendlier to have unique security group names 
and not have to use UUIDs since when there is a need for more than a "default", 
the Tennant admin will want to be able to easily track info related to it, plus 
in the GUI, if it allows a new one to be created, it should disallow "default", 
but should allow modification of that SG.  Also, the GUI could easily suggest 
adding a number or letter to the end of the new name if the one suggested by 
the user is already in use.

So, GUI, logs, and policy issues all rolled into this discussion.

Now to my cause

Log rationalization!  YES!  So, I would classify this as a bug in the logging 
component of Nova.  As Mathieu states, this is a known condition, so this 
should be an ERROR or perhaps WARN that includes which SG name is a duplicate 
(the NoUniqueMatch statement does this, identifying 'default'), and the "Use an 
ID to be more specific" as a helpful pointer.

If a bug has not been filed yet, could you file one, with the pointer to the 
paste file and tag it "log" or "log impact"?  And I'd love if you put me on the 
list of people who should be informed (rockyg).

Thanks for considering the enduser(s) impact of non-unique names.

--Rocky


-Original Message-
From: Mathieu Gagné [mailto:mga...@iweb.com] 
Sent: Thursday, December 11, 2014 3:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id 
in security group

On 2014-12-11 8:43 AM, Jay Pipes 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.
>

We recently had an issue in production where a user had 2 "default" 
security groups (for reasons we have yet to identify). For the sack of 
completeness, we are running Nova+Neutron Icehouse.

When no security group is provided, Nova will default to the "default" 
security group. However due to the fact 2 security groups had the same 
name, nova-compute got confused, put the instance in ERROR state and 
logged this traceback [1]:

   NoUniqueMatch: Multiple security groups found matching 'default'. Use 
an ID to be more specific.

I do understand that people might wish to create security groups with 
the same name.

However I think the following things are very wrong:

- the instance request should be blocked before it ends up on a compute 
node with nova-compute. It shouldn't be the job of nova-compute to find 
out issues about duplicated names. It should be the job of nova-api. 
Don't waste your time scheduling and spawning an instance that will 
never spawn with success.

- From an end user perspective, this means "nova boot" returns no error 
and it's only later that the user is informed of the confusion with 
security group names.

- Why does it have to crash with a traceback? IMO, traceback means "we 
didn't think about this use case, here is more information on how to 
find the source". As an operator, I don't care about the traceback if 
it's a known limitation of Nova/Neutron. Don't pollute my logs with 
"normal exceptions". (Log rationalization anyone?)

Whatever comes out of this discussion about security group name 
uniqueness, I would like those points to be addressed as I feel those 
aren't great users/operators experience.

[1] http://paste.openstack.org/show/149618/

-- 
Mathieu

___
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

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Clint Byrum]

Excerpts from Jay Pipes's message of 2014-12-11 05:43:46 -0800:
> On 12/11/2014 07:22 AM, Anna Kamyshnikova wrote:
> > Hello everyone!
> >
> > In neutron there is a rather old bug [1] about adding uniqueness for
> > security group name and tenant id. I found this idea reasonable and
> > started working on fix for this bug [2]. I think it is good to add a
> > uniqueconstraint because:
> >
> > 1) In nova there is such constraint for security groups
> > https://github.com/openstack/nova/blob/stable/juno/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1155-L1157.
> > So I think that it is rather disruptive that it is impossible to create
> > security group with the same name in nova, but possible in neutron.
> > 2) Users get confused having security groups with the same name.
> >
> > In comment for proposed change Assaf Muller and Maru Newby object for
> > such solution and suggested another option, so I think we need more eyes
> > on this change.
> >
> > I would like to ask you to share your thoughts on this topic.
> > [1] - https://bugs.launchpad.net/neutron/+bug/1194579
> > [2] - https://review.openstack.org/135006
> 
> 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.
> 

The problem with this approach is that it requires the user to have an
external mechanism to achieve idempotency. By allowing an opaque string
that the user submits to you to be guaranteed to be unique, you allow
the user to write "dumber" code around creation in an unreliable
fashion. So instead of


while True:
  try:
item = clientlib.find(name='foo')[0]
break
  except NotFound:
try:
  item = clientlib.create(name='foo')
  break
except UniqueConflict:
  item = clientlib.find(name='foo')[0]
  break

You can keep retrying forever because you know only one thing with that
name will ever exist.

Without unique names, you have to write weird stuff like this to do a
retry.

while len(clientlib.find(name='foo')) < 1:
  try:
item = clientlib.create(name='foo')
list = clientlib.searchfor(name='foo')
for found_item in list:
  if found_item.id != item.id:
clientlib.delete(found_item.id)

Name can certainly remain not-unique and free-form, but don't discount
the value of a unique value that the user specifies.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Mathieu Gagné]

On 2014-12-11 8:43 AM, Jay Pipes 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.



We recently had an issue in production where a user had 2 "default" 
security groups (for reasons we have yet to identify). For the sack of 
completeness, we are running Nova+Neutron Icehouse.


When no security group is provided, Nova will default to the "default" 
security group. However due to the fact 2 security groups had the same 
name, nova-compute got confused, put the instance in ERROR state and 
logged this traceback [1]:


  NoUniqueMatch: Multiple security groups found matching 'default'. Use 
an ID to be more specific.


I do understand that people might wish to create security groups with 
the same name.


However I think the following things are very wrong:

- the instance request should be blocked before it ends up on a compute 
node with nova-compute. It shouldn't be the job of nova-compute to find 
out issues about duplicated names. It should be the job of nova-api. 
Don't waste your time scheduling and spawning an instance that will 
never spawn with success.


- From an end user perspective, this means "nova boot" returns no error 
and it's only later that the user is informed of the confusion with 
security group names.


- Why does it have to crash with a traceback? IMO, traceback means "we 
didn't think about this use case, here is more information on how to 
find the source". As an operator, I don't care about the traceback if 
it's a known limitation of Nova/Neutron. Don't pollute my logs with 
"normal exceptions". (Log rationalization anyone?)


Whatever comes out of this discussion about security group name 
uniqueness, I would like those points to be addressed as I feel those 
aren't great users/operators experience.


[1] http://paste.openstack.org/show/149618/

--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Sean Dague]

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  wrote:
>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:

 On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:

> On Thu, Dec 11, 2014, Mark McClain  wrote:
>>
>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes >> > 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.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Jay Pipes]

On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:

On Dec 11, 2014, at 1:04 PM, Jay Pipes  wrote:

On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:


On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:


On Thu, Dec 11, 2014, Mark McClain  wrote:



On Dec 11, 2014, at 8:43 AM, Jay Pipes 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.

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Vishvananda Ishaya]

On Dec 11, 2014, at 1:04 PM, Jay Pipes  wrote:

> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>> 
>> On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:
>> 
>>> On Thu, Dec 11, 2014, Mark McClain  wrote:
 
> On Dec 11, 2014, at 8:43 AM, Jay Pipes  > 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.

Vish


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Jay Pipes]

On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:


On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:


On Thu, Dec 11, 2014, Mark McClain  wrote:



On Dec 11, 2014, at 8:43 AM, Jay Pipes 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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Vishvananda Ishaya]

On Dec 11, 2014, at 8:00 AM, Henry Gessau  wrote:

> On Thu, Dec 11, 2014, Mark McClain  wrote:
>> 
>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes >> > 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.

Vish




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Henry Gessau]

On Thu, Dec 11, 2014, Mark McClain  wrote:
> 
>> On Dec 11, 2014, at 8:43 AM, Jay Pipes > > 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.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Mark McClain]

> On Dec 11, 2014, at 8:43 AM, Jay Pipes  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.

mark


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Jay Pipes]

On 12/11/2014 07:22 AM, Anna Kamyshnikova wrote:

Hello everyone!

In neutron there is a rather old bug [1] about adding uniqueness for
security group name and tenant id. I found this idea reasonable and
started working on fix for this bug [2]. I think it is good to add a
uniqueconstraint because:

1) In nova there is such constraint for security groups
https://github.com/openstack/nova/blob/stable/juno/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1155-L1157.
So I think that it is rather disruptive that it is impossible to create
security group with the same name in nova, but possible in neutron.
2) Users get confused having security groups with the same name.

In comment for proposed change Assaf Muller and Maru Newby object for
such solution and suggested another option, so I think we need more eyes
on this change.

I would like to ask you to share your thoughts on this topic.
[1] - https://bugs.launchpad.net/neutron/+bug/1194579
[2] - https://review.openstack.org/135006


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.


Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

[Anna Kamyshnikova]

Hello everyone!

In neutron there is a rather old bug [1] about adding uniqueness for
security group name and tenant id. I found this idea reasonable and started
working on fix for this bug [2]. I think it is good to add a
uniqueconstraint because:

1) In nova there is such constraint for security groups
https://github.com/openstack/nova/blob/stable/juno/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1155-L1157.
So I think that it is rather disruptive that it is impossible to create
security group with the same name in nova, but possible in neutron.
2) Users get confused having security groups with the same name.

In comment for proposed change Assaf Muller and Maru Newby object for such
solution and suggested another option, so I think we need more eyes on this
change.

I would like to ask you to share your thoughts on this topic.

[1] - https://bugs.launchpad.net/neutron/+bug/1194579
[2] - https://review.openstack.org/135006
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev