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 <gkot...@redhat.com> 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 <d...@nicira.com> 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 <gkot...@redhat.com> 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@lists.launchpad.net >>> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
