Open Stack

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 <ivarlazzaro at gmail.com>
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 <mark at mcclain.xyz> wrote:
>
>>
>> On Dec 11, 2014, at 8:43 AM, Jay Pipes <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.
>>
>> mark
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141212/b25cba7e/attachment.html>