Open Stack

+2

This kind of confusion is actually very bad from an external perspective  and from a user perspective.

Should this just get resolved by the TC once and for all? I remember this same project vs tenant question happening like 2 years ago (maybe less) and it makes us all look sort if "mad" if we are having it again (especially since it impacts so many components & clients and code, code comments, docs...).

Sent from my really tiny device...

On Nov 23, 2013, at 10:52 AM, "Tim Bell" <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:


To be clear, I don’t care Tenant vs Project. However, I do care that we should not continue this confusion.

One or the other… but not both and a plan to depreciate the other. Naturally, at least 1 release backwards compatibility for environment variables or APIs.

Tim

From: Dean Troyer [mailto:dtroyer at gmail.com]
Sent: 23 November 2013 19:03
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] tenant or project



On Sat, Nov 23, 2013 at 11:35 AM, Dolph Mathews <dolph.mathews at gmail.com<mailto:dolph.mathews at gmail.com>> wrote:
+1 for using the term "project" across all services. Projects provide multi-tenant isolation for resources across the cloud. Part of the reason we prefer "projects" in keystone is that "domains" conceptually provide multi-tenant isolation within keystone itself, so the overloaded "tenant" terminology gets really confusing.

- keystoneclient already supports "projects" from a library perspective (including auth_token)

Thanks you!   I will eventually be able to remove my disparaging comments and work-arounds in OSC for tenantId vs tenant_id!!!

- keystoneclient's CLI is deprecated in favor of openstackclient's CLI, which supports the "project" terminology if you pass the --identity-api-version=3 flag

FWIW I followed Horizon's lead in OSC and removed the tern 'tenant' from all user-visible parts, except for the compatability OS_TENAMT_{ID,NAME} variables and --os-tenant-{id,name} options. Neither of those is documented anywhere though.  This includes commands for all OS APIs it supports.

dt

--

Dean Troyer
dtroyer at gmail.com<mailto:dtroyer at gmail.com>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131124/6f8960e8/attachment.html>