openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

The philosophy from the keystone side of the fence is that once you have
non-unique names you can't go back; whereas, it's trivial to go from unique
to non-unique names. So, without a solid business case to push us in either
direction, we started by enforcing uniqueness.

With the Identity API v3 draft discussions around domains, project/tenant
hierarchies, etc, uniqueness has come up a few times (e.g. continuing to
enforce uniqueness, but not globally... just within a domain/parent
project).

Also, concerning "description" vs "name": identity API v2 currently
provides both fields. In general:

id: keystone managed, globally unique (based on UUID's at the moment)


name: user managed, unique within a keystone deployment


description: non-unique, optional


-Dolph

On Tue, Jul 17, 2012 at 4:35 AM, Gary Kotton <gkotton@xxxxxxxxxx> wrote:

> **
> On 07/17/2012 10:39 AM, Salvatore Orlando wrote:
>
> I don't think either of you is wrong. I too think that in cases where it's
> not easy to find a majority, it might make sense to just do what the other
> projects are doing.
> Unfortunately for us, Keystone adopts the "name is unique" phylosophy,
> whereas nova adopts "name is a label".
>
>  Is it worth considering renaming the attribute to 'name-label' and let
> it be non-unique and non-mandatory?
>
>
> This works for me.
>
>
>  Salvatore
>
> On 16 July 2012 22:27, Dan Wendlandt <dan@xxxxxxxxxx> wrote:
>
>> Hi Gary, this is an example of when I wish openstack APIs had a
>> "style-guide" to try to ensure some consistency across projects.
>>
>>  For those new to the conversation, the original topic of discussion is
>> whether "names" for API objects should be forced to be unique (presumably
>> within a tenant?) or allowed to be duplicated.  The general feeling from
>> the meeting was that since UUIDs are unique, the API itself would not
>> enforce name uniqueness.  That also led to the point that names should then
>> be optional, since they are really for informational/display purposes only.
>>
>>
>>  Personally, I tend to think that "description" tends to imply a
>> sentence "private network for tenant1", rather than a simple name
>> "tenant1-net".  There's also the fact that other openstack services like
>> nova and glance use the term "name" with the similar (I believe) model that
>> a name need not be unique.
>>
>>  Would be curious to hear what others think.  The only thing I'm quite
>> sure about is that there would be value in creating some notion of
>> "openstack API consistency best practices" to give a more cohesive feel to
>> APIs across different projects in the openstack family.
>>
>>  Dan
>>
>>
>> On Mon, Jul 16, 2012 at 10:05 PM, Gary Kotton <gkotton@xxxxxxxxxx> wrote:
>>
>>> Hi,
>>> If the name is intended to be a description then how about the idea of
>>> calling the field "description" instead. This is far more descriptive and
>>> does not lend the user to think that this should be unique.
>>> Thanks
>>> Gary
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>>   --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>