Re: [openstack-dev] tenant or project
On Wed, Nov 27, 2013 at 8:12 AM, Steven Hardy wrote: > On Tue, Nov 26, 2013 at 10:17:56PM +1030, Christopher Yeoh wrote: > > On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco > wrote: > > > On 24/11/13 12:47 -0500, Doug Hellmann wrote: > > > > > >> On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg > > >> wrote: > > >> > > >>In all honesty it doesn't matter which term we go with. As long > as we > > >> are > > >>consistent and define the meaning. I think we can argue intuitive > vs > > >>non-intuitive in this case unto the ground. I prefer "project" to > > >> tenant, > > >>but beyond being a bit of an "overloaded" term, I really don't > think > > >> anyone > > >>will really notice one way or another as long as everything is > using > > >> the > > >>same terminology. We could call it "grouping-of-openstack-things" > if > > >> we > > >>wanted to (though I might have to pull some hair out if we go to > that > > >>terminology). However, with all that in mind, we have made the > > >> choice to move toward > > >>project (horizon, keystone, OSC, keystoneclient) and have some > momentum > > >>behind that push (plus newer projects already use the project > > >>nomenclature). Making a change back to tenant might prove a > worse UX > > >> than > > >>moving everything else in line (nova I think is the one real major > > >> hurdle > > >>to get converted over, and deprecation of keystone v2 API). > > >> > > >> FWIW, ceilometer also uses project in our API (although some of our > docs > > >> use > > >> the terms interchangeably). > > >> > > > > > > And, FWIW, Marconi uses project as well. > > > > > > > > Well project seems to be the way everyone is heading long term. So we'll > > do this for the Nova > > V3 API. As others have mentioned, I think the most important this is > that > > we all end up using > > the same terminology (though with the long life of APIs we're stuck with > > the both for a few years > > at least). > > So, Heat has some work to do as we're still using tenant in various places. > > However, I've been thinking, why do the APIs requests have to contain the > project ID at all? Isn't that something we derive from the token in > auth_token (setting X-Project-Id, which we use to set the project in the > request context)? > +1 > > Maybe I'm missing something obvious, but at the moment, when you create a > heat stack, you specify the tenant ID three times, once in the path, once > in the request body, and again in the context. I'm wondering why, and if > we can kill the first two? > Unless they have different reasons for being, stick with the one in the request context. Users shouldn't have to care about multi-tenancy once they've obtained a scoped token, it should just happen. > > Clearly this is different for keystone, where the top level of request > granularity is Domain not Project, but for all other services, every > request is scoped to a Project is it not? > > Steve > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On Wed, Nov 27, 2013 at 08:17:59AM -0600, Anne Gentle wrote: > Hi Steve, > > There was a long thread about dropping project ID/tenant ID from the URL at > http://openstack.markmail.org/thread/c2wi2uwdsye32z7f > > Looking back through it, it looks like nova v3 has it removed > https://blueprints.launchpad.net/nova/+spec/v3-api-remove-project-id > > Maybe something in there will lend itself to reuse in heat. > Anne Thanks Anne, I knew Nova had removed the ID from the path, but hadn't spotted that they've also removed it from the request body, which is what I'm thinking may make sense for Heat: https://github.com/openstack/nova/blob/master/doc/v3/api_samples/servers/server-post-req.json Looks like we can take a similar path for a future v2 Heat API. Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
Hi Steve, There was a long thread about dropping project ID/tenant ID from the URL at http://openstack.markmail.org/thread/c2wi2uwdsye32z7f Looking back through it, it looks like nova v3 has it removed https://blueprints.launchpad.net/nova/+spec/v3-api-remove-project-id Maybe something in there will lend itself to reuse in heat. Anne On Wed, Nov 27, 2013 at 8:12 AM, Steven Hardy wrote: > On Tue, Nov 26, 2013 at 10:17:56PM +1030, Christopher Yeoh wrote: > > On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco > wrote: > > > On 24/11/13 12:47 -0500, Doug Hellmann wrote: > > > > > >> On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg > > >> wrote: > > >> > > >>In all honesty it doesn't matter which term we go with. As long > as we > > >> are > > >>consistent and define the meaning. I think we can argue intuitive > vs > > >>non-intuitive in this case unto the ground. I prefer "project" to > > >> tenant, > > >>but beyond being a bit of an "overloaded" term, I really don't > think > > >> anyone > > >>will really notice one way or another as long as everything is > using > > >> the > > >>same terminology. We could call it "grouping-of-openstack-things" > if > > >> we > > >>wanted to (though I might have to pull some hair out if we go to > that > > >>terminology). However, with all that in mind, we have made the > > >> choice to move toward > > >>project (horizon, keystone, OSC, keystoneclient) and have some > momentum > > >>behind that push (plus newer projects already use the project > > >>nomenclature). Making a change back to tenant might prove a > worse UX > > >> than > > >>moving everything else in line (nova I think is the one real major > > >> hurdle > > >>to get converted over, and deprecation of keystone v2 API). > > >> > > >> FWIW, ceilometer also uses project in our API (although some of our > docs > > >> use > > >> the terms interchangeably). > > >> > > > > > > And, FWIW, Marconi uses project as well. > > > > > > > > Well project seems to be the way everyone is heading long term. So we'll > > do this for the Nova > > V3 API. As others have mentioned, I think the most important this is > that > > we all end up using > > the same terminology (though with the long life of APIs we're stuck with > > the both for a few years > > at least). > > So, Heat has some work to do as we're still using tenant in various places. > > However, I've been thinking, why do the APIs requests have to contain the > project ID at all? Isn't that something we derive from the token in > auth_token (setting X-Project-Id, which we use to set the project in the > request context)? > > Maybe I'm missing something obvious, but at the moment, when you create a > heat stack, you specify the tenant ID three times, once in the path, once > in the request body, and again in the context. I'm wondering why, and if > we can kill the first two? > > Clearly this is different for keystone, where the top level of request > granularity is Domain not Project, but for all other services, every > request is scoped to a Project is it not? > > Steve > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Anne Gentle annegen...@justwriteclick.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On Tue, Nov 26, 2013 at 10:17:56PM +1030, Christopher Yeoh wrote: > On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco wrote: > > On 24/11/13 12:47 -0500, Doug Hellmann wrote: > > > >> On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg > >> wrote: > >> > >>In all honesty it doesn't matter which term we go with. As long as we > >> are > >>consistent and define the meaning. I think we can argue intuitive vs > >>non-intuitive in this case unto the ground. I prefer "project" to > >> tenant, > >>but beyond being a bit of an "overloaded" term, I really don't think > >> anyone > >>will really notice one way or another as long as everything is using > >> the > >>same terminology. We could call it "grouping-of-openstack-things" if > >> we > >>wanted to (though I might have to pull some hair out if we go to that > >>terminology). However, with all that in mind, we have made the > >> choice to move toward > >>project (horizon, keystone, OSC, keystoneclient) and have some momentum > >>behind that push (plus newer projects already use the project > >>nomenclature). Making a change back to tenant might prove a worse UX > >> than > >>moving everything else in line (nova I think is the one real major > >> hurdle > >>to get converted over, and deprecation of keystone v2 API). > >> > >> FWIW, ceilometer also uses project in our API (although some of our docs > >> use > >> the terms interchangeably). > >> > > > > And, FWIW, Marconi uses project as well. > > > > > Well project seems to be the way everyone is heading long term. So we'll > do this for the Nova > V3 API. As others have mentioned, I think the most important this is that > we all end up using > the same terminology (though with the long life of APIs we're stuck with > the both for a few years > at least). So, Heat has some work to do as we're still using tenant in various places. However, I've been thinking, why do the APIs requests have to contain the project ID at all? Isn't that something we derive from the token in auth_token (setting X-Project-Id, which we use to set the project in the request context)? Maybe I'm missing something obvious, but at the moment, when you create a heat stack, you specify the tenant ID three times, once in the path, once in the request body, and again in the context. I'm wondering why, and if we can kill the first two? Clearly this is different for keystone, where the top level of request granularity is Domain not Project, but for all other services, every request is scoped to a Project is it not? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
Tim Bell wrote: > Can we get a TC policy that 'project' is the standard and that all projects > using tenant should plan a smooth migration path to project along with the > timescales for implementation and retirement of tenant ? Feel free to propose such policy for TC review. Rules of engagement at: https://wiki.openstack.org/wiki/Governance/TechnicalCommittee#Presenting_a_motion_before_the_TC -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
Can we get a TC policy that 'project' is the standard and that all projects using tenant should plan a smooth migration path to project along with the timescales for implementation and retirement of tenant ? Tim From: Christopher Yeoh [mailto:cbky...@gmail.com] Sent: 26 November 2013 12:48 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] tenant or project On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco wrote: On 24/11/13 12:47 -0500, Doug Hellmann wrote: On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg wrote: In all honesty it doesn't matter which term we go with. As long as we are consistent and define the meaning. I think we can argue intuitive vs non-intuitive in this case unto the ground. I prefer "project" to tenant, but beyond being a bit of an "overloaded" term, I really don't think anyone will really notice one way or another as long as everything is using the same terminology. We could call it "grouping-of-openstack-things" if we wanted to (though I might have to pull some hair out if we go to that terminology). However, with all that in mind, we have made the choice to move toward project (horizon, keystone, OSC, keystoneclient) and have some momentum behind that push (plus newer projects already use the project nomenclature). Making a change back to tenant might prove a worse UX than moving everything else in line (nova I think is the one real major hurdle to get converted over, and deprecation of keystone v2 API). FWIW, ceilometer also uses project in our API (although some of our docs use the terms interchangeably). And, FWIW, Marconi uses project as well. Well project seems to be the way everyone is heading long term. So we'll do this for the Nova V3 API. As others have mentioned, I think the most important this is that we all end up using the same terminology (though with the long life of APIs we're stuck with the both for a few years at least). Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On Mon, Nov 25, 2013 at 7:50 PM, Flavio Percoco wrote: > On 24/11/13 12:47 -0500, Doug Hellmann wrote: > >> >> >> >> On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg >> wrote: >> >>In all honesty it doesn't matter which term we go with. As long as we >> are >>consistent and define the meaning. I think we can argue intuitive vs >>non-intuitive in this case unto the ground. I prefer "project" to >> tenant, >>but beyond being a bit of an "overloaded" term, I really don't think >> anyone >>will really notice one way or another as long as everything is using >> the >>same terminology. We could call it "grouping-of-openstack-things" if >> we >>wanted to (though I might have to pull some hair out if we go to that >>terminology). However, with all that in mind, we have made the >> choice to move toward >>project (horizon, keystone, OSC, keystoneclient) and have some momentum >>behind that push (plus newer projects already use the project >>nomenclature). Making a change back to tenant might prove a worse UX >> than >>moving everything else in line (nova I think is the one real major >> hurdle >>to get converted over, and deprecation of keystone v2 API). >> >> FWIW, ceilometer also uses project in our API (although some of our docs >> use >> the terms interchangeably). >> > > And, FWIW, Marconi uses project as well. > > Well project seems to be the way everyone is heading long term. So we'll do this for the Nova V3 API. As others have mentioned, I think the most important this is that we all end up using the same terminology (though with the long life of APIs we're stuck with the both for a few years at least). Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On 24/11/13 12:47 -0500, Doug Hellmann wrote: On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg wrote: In all honesty it doesn't matter which term we go with. As long as we are consistent and define the meaning. I think we can argue intuitive vs non-intuitive in this case unto the ground. I prefer "project" to tenant, but beyond being a bit of an "overloaded" term, I really don't think anyone will really notice one way or another as long as everything is using the same terminology. We could call it "grouping-of-openstack-things" if we wanted to (though I might have to pull some hair out if we go to that terminology). However, with all that in mind, we have made the choice to move toward project (horizon, keystone, OSC, keystoneclient) and have some momentum behind that push (plus newer projects already use the project nomenclature). Making a change back to tenant might prove a worse UX than moving everything else in line (nova I think is the one real major hurdle to get converted over, and deprecation of keystone v2 API). FWIW, ceilometer also uses project in our API (although some of our docs use the terms interchangeably). And, FWIW, Marconi uses project as well. FF -- @flaper87 Flavio Percoco pgpn4defnwUMD.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On Sun, Nov 24, 2013 at 12:08 AM, Morgan Fainberg wrote: > In all honesty it doesn't matter which term we go with. As long as we are > consistent and define the meaning. I think we can argue intuitive vs > non-intuitive in this case unto the ground. I prefer "project" to tenant, > but beyond being a bit of an "overloaded" term, I really don't think anyone > will really notice one way or another as long as everything is using the > same terminology. We could call it "grouping-of-openstack-things" if we > wanted to (though I might have to pull some hair out if we go to that > terminology). > > However, with all that in mind, we have made the choice to move toward > project (horizon, keystone, OSC, keystoneclient) and have some momentum > behind that push (plus newer projects already use the project > nomenclature). Making a change back to tenant might prove a worse UX than > moving everything else in line (nova I think is the one real major hurdle > to get converted over, and deprecation of keystone v2 API). > FWIW, ceilometer also uses project in our API (although some of our docs use the terms interchangeably). Doug > > Cheers, > --Morgan Fainberg > > > On Saturday, November 23, 2013, Caitlin Bestler wrote: > >> I have seen several people request that their users be members of two >> "projects" and that they be allow to publish objects that are "Shared" by >> multiple "projects". >> >> For some reason the people who request these complex data constructions >> always prefer to call the enclosing entity a "project". I have not heard >> such a request for multi-tenant objects and/or users. >> >> The important point is that the "mix and match" approach actually creates >> complex objects where it is difficult to determine who has the right to >> delete them, modify them, change who has access to them, etc. The far >> simpler rule >> is that all objects/resources have a single owner, whether that owner is >> called a "project" or a "tenant". >> >> The term "project", in common english usage, does not have any semantics >> implying exclusivity. Indeed we have "Cross project teams" and resources >> are commonly shared by multiple projects within one company. >> >> The fact that "projects" are typically things *within* a company is >> exactly why it is a poor term for the outermost enclosure of resources. >> > > ___ > 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] tenant or project
+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"
mailto:tim.b...@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:dtro...@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
mailto:dolph.math...@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
dtro...@gmail.com<mailto:dtro...@gmail.com>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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] tenant or project
In all honesty it doesn't matter which term we go with. As long as we are consistent and define the meaning. I think we can argue intuitive vs non-intuitive in this case unto the ground. I prefer "project" to tenant, but beyond being a bit of an "overloaded" term, I really don't think anyone will really notice one way or another as long as everything is using the same terminology. We could call it "grouping-of-openstack-things" if we wanted to (though I might have to pull some hair out if we go to that terminology). However, with all that in mind, we have made the choice to move toward project (horizon, keystone, OSC, keystoneclient) and have some momentum behind that push (plus newer projects already use the project nomenclature). Making a change back to tenant might prove a worse UX than moving everything else in line (nova I think is the one real major hurdle to get converted over, and deprecation of keystone v2 API). Cheers, --Morgan Fainberg On Saturday, November 23, 2013, Caitlin Bestler wrote: > I have seen several people request that their users be members of two > "projects" and that they be allow to publish objects that are "Shared" by > multiple "projects". > > For some reason the people who request these complex data constructions > always prefer to call the enclosing entity a "project". I have not heard > such a request for multi-tenant objects and/or users. > > The important point is that the "mix and match" approach actually creates > complex objects where it is difficult to determine who has the right to > delete them, modify them, change who has access to them, etc. The far > simpler rule > is that all objects/resources have a single owner, whether that owner is > called a "project" or a "tenant". > > The term "project", in common english usage, does not have any semantics > implying exclusivity. Indeed we have "Cross project teams" and resources > are commonly shared by multiple projects within one company. > > The fact that "projects" are typically things *within* a company is > exactly why it is a poor term for the outermost enclosure of resources. > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
I have seen several people request that their users be members of two "projects" and that they be allow to publish objects that are "Shared" by multiple "projects". For some reason the people who request these complex data constructions always prefer to call the enclosing entity a "project". I have not heard such a request for multi-tenant objects and/or users. The important point is that the "mix and match" approach actually creates complex objects where it is difficult to determine who has the right to delete them, modify them, change who has access to them, etc. The far simpler rule is that all objects/resources have a single owner, whether that owner is called a "project" or a "tenant". The term "project", in common english usage, does not have any semantics implying exclusivity. Indeed we have "Cross project teams" and resources are commonly shared by multiple projects within one company. The fact that "projects" are typically things *within* a company is exactly why it is a poor term for the outermost enclosure of resources. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On Sat, Nov 23, 2013 at 2:27 PM, Caitlin Bestler < caitlin.best...@nexenta.com> wrote: > > > On November 23, 2013 4:09:49 AM Christopher Yeoh > wrote: > >> Hi, >> >> So in the past we've used both tenant and project to refer to the same >> thing and I think its been a source of confusion for people new to >> OpenStack. In the Nova code we use both, but at least for the API we've >> been trying to consistently present to the client tenant (which is the >> majority usage) rather than project. >> And then Russell pointed out in https://review.openstack.org/#/c/57612/ >> that the Keystone uses project in the Keystone V3 API rather than >> tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 >> >> I think that we should be consistent across the openstack projects. >> From a very quick look at the core openstack projects I think that they >> mostly use tenant at the moment rather than project. >> >> Does this change in Keystone nomenclature signify that we all should be >> moving to use project rather than tenant in the future (its not >> too late to do a big a search and replace for the Nova V3 API). And is >> the plan for Keystone python client to also change to project rather >> than tenant? >> >> > The advantage of "Tenant" over "project" is that it is far more > intuitively obvious > that resources and users belong to a single tenant than it is that they > belong to > a single project. > You're making a couple assertions here I'd like to discuss individually... 1) it is more intuitive for resources to belong to a single tenant than it is to belong to a single project Do you have any justification for this? I personally don't find this more intuitive at all, but it's certainly subject. I frequently create new projects to play around with compute instances, etc, and delete the project when I'm done. The term "project" fits that really well. If we're using the term "tenant" in this example, it sounds like a I have to provide new billing information every time I want to goof around, which is not appealing at all. - it is more intuitive for user to "belong to" a single tenant than it is to belong to a single project First of all, I absolutely despise the phrasing "users belong to tenants" because it's both vague and wrong. Projects do not own or belong to users. Users do not own or belong to projects. One identity can hold explicit authorization in one or more projects via role assignments, group membership, etc. It's a many-to-many relationship. The distinction between "tenant" and "project" here is entirely inconsequential because the statement being made is fundamentally flawed to begin with. > > Companies that are the customers of data centers are likely to have many > "projects", and want their employees to have access to multiple projects. > ++ > I think we are better off with a label that creates a clear expectation of > one-bill-payer equals one-tenant. > This seems to contradict your previous statement entirely. Alternatively, you could have "one-bill-payer equals one-domain," where each domain contains multiple cloud projects with distinct sets of cloud resources all being aggregated together for billing purposes. As a customer of a data center, I might be running production, staging, continuous build, and development environments all as separate tenants/projects. Why would you want my billing information 100 times a month? > > All the data is far simpler with that rule. What data is simpler in what way with what rule? > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On November 23, 2013 4:09:49 AM Christopher Yeoh wrote: Hi, So in the past we've used both tenant and project to refer to the same thing and I think its been a source of confusion for people new to OpenStack. In the Nova code we use both, but at least for the API we've been trying to consistently present to the client tenant (which is the majority usage) rather than project. And then Russell pointed out in https://review.openstack.org/#/c/57612/ that the Keystone uses project in the Keystone V3 API rather than tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 I think that we should be consistent across the openstack projects. From a very quick look at the core openstack projects I think that they mostly use tenant at the moment rather than project. Does this change in Keystone nomenclature signify that we all should be moving to use project rather than tenant in the future (its not too late to do a big a search and replace for the Nova V3 API). And is the plan for Keystone python client to also change to project rather than tenant? The advantage of "Tenant" over "project" is that it is far more intuitively obvious that resources and users belong to a single tenant than it is that they belong to a single project. Companies that are the customers of data centers are likely to have many "projects", and want their employees to have access to multiple projects. I think we are better off with a label that creates a clear expectation of one-bill-payer equals one-tenant. All the data is far simpler with that rule. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
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:dtro...@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
mailto:dolph.math...@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
dtro...@gmail.com<mailto:dtro...@gmail.com>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On Sat, Nov 23, 2013 at 11:35 AM, Dolph Mathews 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
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
+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. It's been a slow process to kill the term "tenant" in keystone, here's the current status: - the v2.0 API is finally being deprecated altogether, which should be the last mentions of "tenant" - the v3 API speaks in terms of "projects" - keystoneclient already supports "projects" from a library perspective (including auth_token) - 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 On Sat, Nov 23, 2013 at 7:48 AM, Anne Gentle wrote: > Project is what Keystone chose to standardize on for their v3 API. Lots of > other APIs are affected as you can imagine. > > Here's a thread http://openstack.markmail.org/thread/wyce6kvkfqexcpuu > > +1, everything mentioned in that email has now happened :) > Anne > > > On Sat, Nov 23, 2013 at 7:07 AM, Nick Chase wrote: > >> From a purely documentation and explanatory standpoint I vote for >> "project", if we're going to standardize on one or the other. >> On Nov 23, 2013 7:13 AM, "Christopher Yeoh" wrote: >> >>> Hi, >>> >>> So in the past we've used both tenant and project to refer to the same >>> thing and I think its been a source of confusion for people new to >>> OpenStack. In the Nova code we use both, but at least for the API we've >>> been trying to consistently present to the client tenant (which is the >>> majority usage) rather than project. >>> >>> And then Russell pointed out in https://review.openstack.org/#/c/57612/ >>> that the Keystone uses project in the Keystone V3 API rather than >>> tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 >>> >>> I think that we should be consistent across the openstack projects. >>> From a very quick look at the core openstack projects I think that they >>> mostly use tenant at the moment rather than project. >>> >>> Does this change in Keystone nomenclature signify that we all should be >>> moving to use project rather than tenant in the future (its not >>> too late to do a big a search and replace for the Nova V3 API). And is >>> the plan for Keystone python client to also change to project rather >>> than tenant? >>> >>> Chris >>> >>> ___ >>> 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 >> >> > > > -- > Anne Gentle > annegen...@justwriteclick.com > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
On 11/23/2013 08:28 AM, Tim Bell wrote: > > Horizon uses Project in the user interface, yet the openstack.rc file > contains tenant_id and tenant_name. It makes it very difficult to write user > guides given that such a fundamental concept has two names. +1. I struggled with this dual-nomenclature when writing up a security note earlier this week. I discussed it with Adam from the Keystone project, and he said that they want the tenant term to go away and be replaced by project. This is even mentioned in their v3 API docs: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#whats-new-in-version-30 > > No problem to maintain compatibility (i.e. try OS_TENANT_NAME after > OS_PROJECT_NAME) but the lack of convergence is not helping new user adoption. > > How about the technical committee makes a statement that by Icehouse we align > all user facing definitions to Tenant or Project (while maintaining backwards > compatibility on the environment variables) ? I think that this is absolutely needed. -NGK > > Tim > >> -Original Message- >> From: Christopher Yeoh [mailto:cbky...@gmail.com] >> Sent: 23 November 2013 13:10 >> To: openstack-dev@lists.openstack.org >> Subject: [openstack-dev] tenant or project >> >> Hi, >> >> So in the past we've used both tenant and project to refer to the same thing >> and I think its been a source of confusion for people new to >> OpenStack. In the Nova code we use both, but at least for the API we've been >> trying to consistently present to the client tenant (which is >> the majority usage) rather than project. >> >> And then Russell pointed out in https://review.openstack.org/#/c/57612/ >> that the Keystone uses project in the Keystone V3 API rather than tenant. >> http://api.openstack.org/api-ref-identity.html#identity-v3 >> >> I think that we should be consistent across the openstack projects. >> From a very quick look at the core openstack projects I think that they >> mostly use tenant at the moment rather than project. >> >> Does this change in Keystone nomenclature signify that we all should be >> moving to use project rather than tenant in the future (its not too >> late to do a big a search and replace for the Nova V3 API). And is the plan >> for Keystone python client to also change to project rather than >> tenant? >> >> Chris >> >> ___ >> 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
Horizon uses Project in the user interface, yet the openstack.rc file contains tenant_id and tenant_name. It makes it very difficult to write user guides given that such a fundamental concept has two names. No problem to maintain compatibility (i.e. try OS_TENANT_NAME after OS_PROJECT_NAME) but the lack of convergence is not helping new user adoption. How about the technical committee makes a statement that by Icehouse we align all user facing definitions to Tenant or Project (while maintaining backwards compatibility on the environment variables) ? Tim > -Original Message- > From: Christopher Yeoh [mailto:cbky...@gmail.com] > Sent: 23 November 2013 13:10 > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] tenant or project > > Hi, > > So in the past we've used both tenant and project to refer to the same thing > and I think its been a source of confusion for people new to > OpenStack. In the Nova code we use both, but at least for the API we've been > trying to consistently present to the client tenant (which is > the majority usage) rather than project. > > And then Russell pointed out in https://review.openstack.org/#/c/57612/ > that the Keystone uses project in the Keystone V3 API rather than tenant. > http://api.openstack.org/api-ref-identity.html#identity-v3 > > I think that we should be consistent across the openstack projects. > From a very quick look at the core openstack projects I think that they > mostly use tenant at the moment rather than project. > > Does this change in Keystone nomenclature signify that we all should be > moving to use project rather than tenant in the future (its not too > late to do a big a search and replace for the Nova V3 API). And is the plan > for Keystone python client to also change to project rather than > tenant? > > Chris > > ___ > 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] tenant or project
Project is what Keystone chose to standardize on for their v3 API. Lots of other APIs are affected as you can imagine. Here's a thread http://openstack.markmail.org/thread/wyce6kvkfqexcpuu Anne On Sat, Nov 23, 2013 at 7:07 AM, Nick Chase wrote: > From a purely documentation and explanatory standpoint I vote for > "project", if we're going to standardize on one or the other. > On Nov 23, 2013 7:13 AM, "Christopher Yeoh" wrote: > >> Hi, >> >> So in the past we've used both tenant and project to refer to the same >> thing and I think its been a source of confusion for people new to >> OpenStack. In the Nova code we use both, but at least for the API we've >> been trying to consistently present to the client tenant (which is the >> majority usage) rather than project. >> >> And then Russell pointed out in https://review.openstack.org/#/c/57612/ >> that the Keystone uses project in the Keystone V3 API rather than >> tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 >> >> I think that we should be consistent across the openstack projects. >> From a very quick look at the core openstack projects I think that they >> mostly use tenant at the moment rather than project. >> >> Does this change in Keystone nomenclature signify that we all should be >> moving to use project rather than tenant in the future (its not >> too late to do a big a search and replace for the Nova V3 API). And is >> the plan for Keystone python client to also change to project rather >> than tenant? >> >> Chris >> >> ___ >> 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 > > -- Anne Gentle annegen...@justwriteclick.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] tenant or project
>From a purely documentation and explanatory standpoint I vote for "project", if we're going to standardize on one or the other. On Nov 23, 2013 7:13 AM, "Christopher Yeoh" wrote: > Hi, > > So in the past we've used both tenant and project to refer to the same > thing and I think its been a source of confusion for people new to > OpenStack. In the Nova code we use both, but at least for the API we've > been trying to consistently present to the client tenant (which is the > majority usage) rather than project. > > And then Russell pointed out in https://review.openstack.org/#/c/57612/ > that the Keystone uses project in the Keystone V3 API rather than > tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 > > I think that we should be consistent across the openstack projects. > From a very quick look at the core openstack projects I think that they > mostly use tenant at the moment rather than project. > > Does this change in Keystone nomenclature signify that we all should be > moving to use project rather than tenant in the future (its not > too late to do a big a search and replace for the Nova V3 API). And is > the plan for Keystone python client to also change to project rather > than tenant? > > Chris > > ___ > 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
[openstack-dev] tenant or project
Hi, So in the past we've used both tenant and project to refer to the same thing and I think its been a source of confusion for people new to OpenStack. In the Nova code we use both, but at least for the API we've been trying to consistently present to the client tenant (which is the majority usage) rather than project. And then Russell pointed out in https://review.openstack.org/#/c/57612/ that the Keystone uses project in the Keystone V3 API rather than tenant. http://api.openstack.org/api-ref-identity.html#identity-v3 I think that we should be consistent across the openstack projects. >From a very quick look at the core openstack projects I think that they mostly use tenant at the moment rather than project. Does this change in Keystone nomenclature signify that we all should be moving to use project rather than tenant in the future (its not too late to do a big a search and replace for the Nova V3 API). And is the plan for Keystone python client to also change to project rather than tenant? Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
