Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Smigiel, Dariusz]

Thanks guys for all the feedback.
I'm happy we elaborated some plan for this topic.

-- 
 Dariusz Smigiel
 Intel Technology Poland

> On 12/04/2015 04:26 PM, Armando M. wrote:
> >
> >
> > On 4 December 2015 at 10:02, Kevin Benton  > > wrote:
> >
> > So obviously the stuff in the client can be updated since most of
> > that is user-facing. However, on the server side maybe we can start
> > out by keeping all of the internal code and DB tables the same. Then
> > all we need to worry about is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the
> > transition to project_id internally at our own pace and in much less
> > invasive chunks.
> >
> >
> > This plan is sensible, and kudos to Dariusz to take it on...this is no
> > small feat of engineering and it won't be the effort of a
> > single...we're all here to help. Let me state the obvious and remind
> > that this is not a mechanical search and replace effort. We gotta be
> > extra careful to support both terms in the process.
> >
> > To sum it up I see the following steps:
> >
> > 1) Make or figure out how the server can talk to the v3 API - which is
> > bug 1503428. If Monty is unable to tackle it soon, I am sure he'll be
> > happy to hand it back and Darius, perhaps, can take over
> 
> I will hack on this next week - sorry for the delay so far. I'd love to do a 
> first
> rough pass and then get Darius to look at it and tell me where I'm insane.
> 
> > This will ensure that if for whatever reason v2 gets pulled out
> > tomorrow (not gonna happen, but still), we're not left high and dry.
> > To achieve this, I think we don't invasively need to change tenant id
> > with project id, but only where it's key to get/validate a token.
> 
> ++
> 
> > 2) Start from the client to allow to handle both project_id and tenant_id.
> >
> > The server must be enhanced to be able to convert project_id to
> > tenant_id on the fly. The change should be relatively limited in a few
> > places, like where the request come in. At this time nothing else is
> > required to change in the server.
> 
>  From an auth perspective, keystoneauth will handle both tenant and project
> as auth parameters (and I've got a patch coming to neutronclient to help get
> that all fleshed out too)
> 
>  From the server/api side and client lib side where people are passing in
> tenant_ids to neutron resources because it's important to associate a
> resource with a tenant/project - I think this is a GREAT plan, and thank you
> for doing it this way. As a consumer of your API, I neither want to have to
> change my code to the new version, or write new code using the old version
> (thus perpetuating the move in history)
> 
> I would suggest/request if there is a way (and this might be _terrible_ to
> mark tenant_id in the _docs_ as either hidden or deprecated, so that new
> users don't write new code using it - but of course we should continue to
> accept tenant_id until the end of time because of how much we love our
> users.
> 
> > 3) Tackle the data model.
> >
> > I wonder if we could leverage some sqlalchemy magic to support both
> > project_id and tenant_id in the db logic, seamlesslysomething
> > worth investigating (zzzeek may be of help here). The sooner we start
> > here, the sooner we catch and fix breakages
> >
> > 4) Tackle the codebase sweep.
> >
> > As for projects that use neutron and use the internal APIs, I can't
> > see a clean way of handling the bw compat if not by sprinkling
> > decorators that will take the signature of all the affected methods
> > and convert the tenant_id, but we could definitely explore how this would
> look like.
> 
> Yah. That one is going to be yuck. I'm happy to hand people beer ... :)
> >
> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz
> > mailto:dariusz.smig...@intel.com>> wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in
> > Mitaka [6], and probably forever. It will stay at least four
> > releases, but we need to decide, how to conquer problem of
> > renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of
> > 'tenant' to 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013
> > [4][5] but unfortunately, no one finished it. Although Keystone
> > V3 API is already supported in Neutron client [2], there are
> > still some unknowns about Neutron server side. Monty Taylor is
> > trying to address necessary (if any) changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server
> >

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Monty Taylor]

On 12/04/2015 04:26 PM, Armando M. wrote:



On 4 December 2015 at 10:02, Kevin Benton mailto:blak...@gmail.com>> wrote:

So obviously the stuff in the client can be updated since most of
that is user-facing. However, on the server side maybe we can start
out by keeping all of the internal code and DB tables the same. Then
all we need to worry about is the API translation code to start.

Once our public-facing stuff is done, we can just start the
transition to project_id internally at our own pace and in much less
invasive chunks.


This plan is sensible, and kudos to Dariusz to take it on...this is no
small feat of engineering and it won't be the effort of a single...we're
all here to help. Let me state the obvious and remind that this is not a
mechanical search and replace effort. We gotta be extra careful to
support both terms in the process.

To sum it up I see the following steps:

1) Make or figure out how the server can talk to the v3 API - which is
bug 1503428. If Monty is unable to tackle it soon, I am sure he'll be
happy to hand it back and Darius, perhaps, can take over


I will hack on this next week - sorry for the delay so far. I'd love to 
do a first rough pass and then get Darius to look at it and tell me 
where I'm insane.



This will ensure that if for whatever reason v2 gets pulled out tomorrow
(not gonna happen, but still), we're not left high and dry. To achieve
this, I think we don't invasively need to change tenant id with project
id, but only where it's key to get/validate a token.


++


2) Start from the client to allow to handle both project_id and tenant_id.

The server must be enhanced to be able to convert project_id to
tenant_id on the fly. The change should be relatively limited in a few
places, like where the request come in. At this time nothing else is
required to change in the server.


From an auth perspective, keystoneauth will handle both tenant and 
project as auth parameters (and I've got a patch coming to neutronclient 
to help get that all fleshed out too)


From the server/api side and client lib side where people are passing 
in tenant_ids to neutron resources because it's important to associate a 
resource with a tenant/project - I think this is a GREAT plan, and thank 
you for doing it this way. As a consumer of your API, I neither want to 
have to change my code to the new version, or write new code using the 
old version (thus perpetuating the move in history)


I would suggest/request if there is a way (and this might be _terrible_ 
to mark tenant_id in the _docs_ as either hidden or deprecated, so that 
new users don't write new code using it - but of course we should 
continue to accept tenant_id until the end of time because of how much 
we love our users.



3) Tackle the data model.

I wonder if we could leverage some sqlalchemy magic to support both
project_id and tenant_id in the db logic, seamlesslysomething worth
investigating (zzzeek may be of help here). The sooner we start here,
the sooner we catch and fix breakages

4) Tackle the codebase sweep.

As for projects that use neutron and use the internal APIs, I can't see
a clean way of handling the bw compat if not by sprinkling decorators
that will take the signature of all the affected methods and convert the
tenant_id, but we could definitely explore how this would look like.


Yah. That one is going to be yuck. I'm happy to hand people beer ... :)



On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz
mailto:dariusz.smig...@intel.com>> wrote:

Hey Neutrinos (thanks armax for this word :),
Keystone is planning to deprecate V2 API (again :). This time in
Mitaka [6], and probably forever. It will stay at least four
releases, but we need to decide, how to conquer problem of
renaming...
And more important: consider if it's a problem for Neutron?

I'm looking at blueprint [1] about renaming all occurrences of
'tenant' to 'project', and trying to find out all the details.
First attempt to solve this problem was raised in November 2013
[4][5] but unfortunately, no one finished it. Although Keystone
V3 API is already supported in Neutron client [2], there are
still some unknowns about Neutron server side. Monty Taylor is
trying to address necessary (if any) changes [3].

Findings:
I've focused on two projects: python-neutronclient and neutron.
grep found 429 occurrences of 'tenant' in Client while Server
has 3021 of it. Some of them are just documentation and
docstrings, but there are a lot of places, where variables are
tangled: defined in DB, used in server, accessed by client. Most
of places are just internal usages. The only thing where I've
found 'public' information about tenants is 'help' command in
neutron client.

Suggested plan for conquer:
1. First step would be to

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Armando M.]

On 4 December 2015 at 13:33, Neil Jerram  wrote:

> Really?  I don't want to escalate, but I  think that I'm entitled:
>
>
> - to have an opinion on this, regardless of how much of the history I've
> read
>
>
> - to express that opinion in response to an explicit request for "any
> feedback", particularly when no one else had responded to that call for
> nearly 24 hours.
>
> FWIW, it's also fine with me that there is apparently a strong consensus
> _for_ this change, and I'm happy to reflect and ponder that my intuition
> might be wrong.  I'd rather have stuck my neck out and contributed to a
> discussion, than be asked later "why did no one say anything?"
>

Of course you're entitled to an opinion, no-one is taking that away from
you. All I am saying is that things may not sound so silly as you claim if
you knew the whole story, that's all!

>
> Neil
>
> --
> *From:* Armando M. 
> *Sent:* 04 December 2015 21:01
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] Rename tenant to project:
> discussion
>
>
>
> On 4 December 2015 at 08:46, Neil Jerram 
> wrote:
>
>> I'm new to this discussion, but you did ask for any feedback, so ...
>>
>> On 03/12/15 18:29, Smigiel, Dariusz wrote:
>> > Hey Neutrinos (thanks armax for this word :),
>> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
>> [6], and probably forever. It will stay at least four releases, but we need
>> to decide, how to conquer problem of renaming...
>> > And more important: consider if it's a problem for Neutron?
>> >
>> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
>> to 'project', and trying to find out all the details.
>> > First attempt to solve this problem was raised in November 2013 [4][5]
>> but unfortunately, no one finished it. Although Keystone V3 API is already
>> supported in Neutron client [2], there are still some unknowns about
>> Neutron server side. Monty Taylor is trying to address necessary (if any)
>> changes [3].
>> >
>> > Findings:
>> > I've focused on two projects: python-neutronclient and neutron.
>> > grep found 429 occurrences of 'tenant' in Client while Server has 3021
>> of it. Some of them are just documentation and docstrings, but there are a
>> lot of places, where variables are tangled: defined in DB, used in server,
>> accessed by client. Most of places are just internal usages. The only thing
>> where I've found 'public' information about tenants is 'help' command in
>> neutron client.
>> >
>> > Suggested plan for conquer:
>> > 1. First step would be to deal with neutronclient. It's much smaller
>> amount of code to look through, update all places and be successful :)
>> > 2. Bigger challenge will be to change server side code. I'd suggest to
>> start with renaming db columns. It affects a lot of places, so when
>> finished should significantly lower number of remained "tenants".
>> > 3. Deal with all other places.
>> >
>> > Pros:
>> > - variable names unification in OpenStack code base. Someone needs to
>> start this job.
>> > - one way to describe the same thing, instead of:
>> tenant/account/project. Helpful, especially for newcomers.
>> > - alignment with Keystone V3 API
>> >
>> > Cons:
>> > - A. Lot. Of. Work.
>> > - dealing with DB migrations
>> > - about 2-4 weeks of work for every part of code. Additional, a lot of
>> patchsets to be reviewed.
>> >
>> > What do you think about this? About proposed way of dealing with all
>> changes?
>> > Is this change necessary?
>>
>> My intuition is that we should just not do this change.  The whole world
>> says 'tenant' for the 'tenant' concept, particularly in the context of
>> networking.  Changing to a different term is just silly.
>>
>>
> If you don't know the whole story why are you making these remarks?
>
>
>> But I haven't looked into the history.  Perhaps there's some reason we
>> need to anyway.
>
>
>> Neil
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Neil Jerram]

Really?  I don't want to escalate, but I  think that I'm entitled:


- to have an opinion on this, regardless of how much of the history I've read


- to express that opinion in response to an explicit request for "any 
feedback", particularly when no one else had responded to that call for nearly 
24 hours.


FWIW, it's also fine with me that there is apparently a strong consensus _for_ 
this change, and I'm happy to reflect and ponder that my intuition might be 
wrong.  I'd rather have stuck my neck out and contributed to a discussion, than 
be asked later "why did no one say anything?"


Neil


From: Armando M. 
Sent: 04 December 2015 21:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Rename tenant to project: discussion



On 4 December 2015 at 08:46, Neil Jerram 
mailto:neil.jer...@metaswitch.com>> wrote:
I'm new to this discussion, but you did ask for any feedback, so ...

On 03/12/15 18:29, Smigiel, Dariusz wrote:
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
> and probably forever. It will stay at least four releases, but we need to 
> decide, how to conquer problem of renaming...
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but 
> unfortunately, no one finished it. Although Keystone V3 API is already 
> supported in Neutron client [2], there are still some unknowns about Neutron 
> server side. Monty Taylor is trying to address necessary (if any) changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
> Some of them are just documentation and docstrings, but there are a lot of 
> places, where variables are tangled: defined in DB, used in server, accessed 
> by client. Most of places are just internal usages. The only thing where I've 
> found 'public' information about tenants is 'help' command in neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller amount 
> of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to start 
> with renaming db columns. It affects a lot of places, so when finished should 
> significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to start 
> this job.
> - one way to describe the same thing, instead of: tenant/account/project. 
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of 
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all changes?
> Is this change necessary?

My intuition is that we should just not do this change.  The whole world
says 'tenant' for the 'tenant' concept, particularly in the context of
networking.  Changing to a different term is just silly.


If you don't know the whole story why are you making these remarks?

But I haven't looked into the history.  Perhaps there's some reason we
need to anyway.

Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Armando M.]

On 4 December 2015 at 10:02, Kevin Benton  wrote:

> So obviously the stuff in the client can be updated since most of that is
> user-facing. However, on the server side maybe we can start out by keeping
> all of the internal code and DB tables the same. Then all we need to worry
> about is the API translation code to start.
>
> Once our public-facing stuff is done, we can just start the transition to
> project_id internally at our own pace and in much less invasive chunks.
>

This plan is sensible, and kudos to Dariusz to take it on...this is no
small feat of engineering and it won't be the effort of a single...we're
all here to help. Let me state the obvious and remind that this is not a
mechanical search and replace effort. We gotta be extra careful to support
both terms in the process.

To sum it up I see the following steps:

1) Make or figure out how the server can talk to the v3 API - which is bug
1503428. If Monty is unable to tackle it soon, I am sure he'll be happy to
hand it back and Darius, perhaps, can take over

This will ensure that if for whatever reason v2 gets pulled out tomorrow
(not gonna happen, but still), we're not left high and dry. To achieve
this, I think we don't invasively need to change tenant id with project id,
but only where it's key to get/validate a token.

2) Start from the client to allow to handle both project_id and tenant_id.

The server must be enhanced to be able to convert project_id to tenant_id
on the fly. The change should be relatively limited in a few places, like
where the request come in. At this time nothing else is required to change
in the server.

3) Tackle the data model.

I wonder if we could leverage some sqlalchemy magic to support both
project_id and tenant_id in the db logic, seamlesslysomething worth
investigating (zzzeek may be of help here). The sooner we start here, the
sooner we catch and fix breakages

4) Tackle the codebase sweep.

As for projects that use neutron and use the internal APIs, I can't see a
clean way of handling the bw compat if not by sprinkling decorators that
will take the signature of all the affected methods and convert the
tenant_id, but we could definitely explore how this would look like.


> On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <
> dariusz.smig...@intel.com> wrote:
>
>> Hey Neutrinos (thanks armax for this word :),
>> Keystone is planning to deprecate V2 API (again :). This time in Mitaka
>> [6], and probably forever. It will stay at least four releases, but we need
>> to decide, how to conquer problem of renaming...
>> And more important: consider if it's a problem for Neutron?
>>
>> I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
>> to 'project', and trying to find out all the details.
>> First attempt to solve this problem was raised in November 2013 [4][5]
>> but unfortunately, no one finished it. Although Keystone V3 API is already
>> supported in Neutron client [2], there are still some unknowns about
>> Neutron server side. Monty Taylor is trying to address necessary (if any)
>> changes [3].
>>
>> Findings:
>> I've focused on two projects: python-neutronclient and neutron.
>> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of
>> it. Some of them are just documentation and docstrings, but there are a lot
>> of places, where variables are tangled: defined in DB, used in server,
>> accessed by client. Most of places are just internal usages. The only thing
>> where I've found 'public' information about tenants is 'help' command in
>> neutron client.
>>
>> Suggested plan for conquer:
>> 1. First step would be to deal with neutronclient. It's much smaller
>> amount of code to look through, update all places and be successful :)
>> 2. Bigger challenge will be to change server side code. I'd suggest to
>> start with renaming db columns. It affects a lot of places, so when
>> finished should significantly lower number of remained "tenants".
>> 3. Deal with all other places.
>>
>> Pros:
>> - variable names unification in OpenStack code base. Someone needs to
>> start this job.
>> - one way to describe the same thing, instead of: tenant/account/project.
>> Helpful, especially for newcomers.
>> - alignment with Keystone V3 API
>>
>> Cons:
>> - A. Lot. Of. Work.
>> - dealing with DB migrations
>> - about 2-4 weeks of work for every part of code. Additional, a lot of
>> patchsets to be reviewed.
>>
>> What do you think about this? About proposed way of dealing with all
>> changes?
>> Is this change necessary?
>> Did I forget about something?
>>
>> I'll be grateful for any kind of feedback.
>>
>> Thanks,
>>  Dariusz Smigiel (dasm)
>>  Intel Technology Poland
>>
>> [1]
>> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
>> [2]
>> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
>> [3] https://bugs.launchpad.net/neutron/+bug/1503428
>> [4]
>> http://lists.openstack.org/pipermail/openstack-dev/2013-November/0

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Armando M.]

On 4 December 2015 at 08:46, Neil Jerram  wrote:

> I'm new to this discussion, but you did ask for any feedback, so ...
>
> On 03/12/15 18:29, Smigiel, Dariusz wrote:
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> [6], and probably forever. It will stay at least four releases, but we need
> to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
> to 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013 [4][5]
> but unfortunately, no one finished it. Although Keystone V3 API is already
> supported in Neutron client [2], there are still some unknowns about
> Neutron server side. Monty Taylor is trying to address necessary (if any)
> changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has 3021
> of it. Some of them are just documentation and docstrings, but there are a
> lot of places, where variables are tangled: defined in DB, used in server,
> accessed by client. Most of places are just internal usages. The only thing
> where I've found 'public' information about tenants is 'help' command in
> neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> amount of code to look through, update all places and be successful :)
> > 2. Bigger challenge will be to change server side code. I'd suggest to
> start with renaming db columns. It affects a lot of places, so when
> finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> start this job.
> > - one way to describe the same thing, instead of:
> tenant/account/project. Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot of
> patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all
> changes?
> > Is this change necessary?
>
> My intuition is that we should just not do this change.  The whole world
> says 'tenant' for the 'tenant' concept, particularly in the context of
> networking.  Changing to a different term is just silly.
>
>
If you don't know the whole story why are you making these remarks?


> But I haven't looked into the history.  Perhaps there's some reason we
> need to anyway.


> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Doug Wiegley]

> On Dec 4, 2015, at 12:40 PM, Kyle Mestery  wrote:
> 
> On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau  > wrote:
> Kevin Benton mailto:blak...@gmail.com>> wrote:
> > So obviously the stuff in the client can be updated since most of that is
> > user-facing. However, on the server side maybe we can start out by keeping 
> > all
> > of the internal code and DB tables the same. Then all we need to worry about
> > is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the transition to
> > project_id internally at our own pace and in much less invasive chunks.
> 
> I agree with Kevin's suggestion.
> 
> 
> ++, and this is what Salvatore has previously suggested as well.

There was general consensus around this at the last neutron meeting, too.

And one thing missing from your analysis is subprojects that import neutron. 
Many will be referencing tenant or tenant_id in methods, models, or dicts, and 
though those are “internal”, providing backwards compatibility would be a sane 
thing to consider.

Thanks,
dogu



>  
> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz 
> > mailto:dariusz.smig...@intel.com>
> > >> 
> > wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> > [6], and probably forever. It will stay at least four releases, but we
> > need to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant' 
> > to
> > 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013 [4][5] 
> > but
> > unfortunately, no one finished it. Although Keystone V3 API is already
> > supported in Neutron client [2], there are still some unknowns about
> > Neutron server side. Monty Taylor is trying to address necessary (if 
> > any)
> > changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has 3021 
> > of
> > it. Some of them are just documentation and docstrings, but there are a
> > lot of places, where variables are tangled: defined in DB, used in 
> > server,
> > accessed by client. Most of places are just internal usages. The only
> > thing where I've found 'public' information about tenants is 'help'
> > command in neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> > amount of code to look through, update all places and be successful :)
> > 2. Bigger challenge will be to change server side code. I'd suggest to
> > start with renaming db columns. It affects a lot of places, so when
> > finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> > start this job.
> > - one way to describe the same thing, instead of: 
> > tenant/account/project.
> > Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot of
> > patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all 
> > changes?
> > Is this change necessary?
> > Did I forget about something?
> >
> > I'll be grateful for any kind of feedback.
> >
> > Thanks,
> >  Dariusz Smigiel (dasm)
> >  Intel Technology Poland
> >
> > [1] 
> > https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project 
> > 
> > [2]
> > 
> > https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> >  
> > 
> > [3] https://bugs.launchpad.net/neutron/+bug/1503428 
> > 
> > [4]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> >  
> > 
> > [5]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> >  
> > 
> > [6]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm 
> > 
> >
> 
> 
> 

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Kyle Mestery]

On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau  wrote:

> Kevin Benton  wrote:
> > So obviously the stuff in the client can be updated since most of that is
> > user-facing. However, on the server side maybe we can start out by
> keeping all
> > of the internal code and DB tables the same. Then all we need to worry
> about
> > is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the transition to
> > project_id internally at our own pace and in much less invasive chunks.
>
> I agree with Kevin's suggestion.
>
>
++, and this is what Salvatore has previously suggested as well.


> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <
> dariusz.smig...@intel.com
> > > wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in
> Mitaka
> > [6], and probably forever. It will stay at least four releases, but
> we
> > need to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of
> 'tenant' to
> > 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013
> [4][5] but
> > unfortunately, no one finished it. Although Keystone V3 API is
> already
> > supported in Neutron client [2], there are still some unknowns about
> > Neutron server side. Monty Taylor is trying to address necessary (if
> any)
> > changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has
> 3021 of
> > it. Some of them are just documentation and docstrings, but there
> are a
> > lot of places, where variables are tangled: defined in DB, used in
> server,
> > accessed by client. Most of places are just internal usages. The only
> > thing where I've found 'public' information about tenants is 'help'
> > command in neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> > amount of code to look through, update all places and be successful
> :)
> > 2. Bigger challenge will be to change server side code. I'd suggest
> to
> > start with renaming db columns. It affects a lot of places, so when
> > finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> > start this job.
> > - one way to describe the same thing, instead of:
> tenant/account/project.
> > Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot
> of
> > patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all
> changes?
> > Is this change necessary?
> > Did I forget about something?
> >
> > I'll be grateful for any kind of feedback.
> >
> > Thanks,
> >  Dariusz Smigiel (dasm)
> >  Intel Technology Poland
> >
> > [1]
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
> > [2]
> >
> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> > [3] https://bugs.launchpad.net/neutron/+bug/1503428
> > [4]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> > [5]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> > [6]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Henry Gessau]

Kevin Benton  wrote:
> So obviously the stuff in the client can be updated since most of that is
> user-facing. However, on the server side maybe we can start out by keeping all
> of the internal code and DB tables the same. Then all we need to worry about
> is the API translation code to start.
> 
> Once our public-facing stuff is done, we can just start the transition to
> project_id internally at our own pace and in much less invasive chunks.

I agree with Kevin's suggestion.

> On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz  > wrote:
> 
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> [6], and probably forever. It will stay at least four releases, but we
> need to decide, how to conquer problem of renaming...
> And more important: consider if it's a problem for Neutron?
> 
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but
> unfortunately, no one finished it. Although Keystone V3 API is already
> supported in Neutron client [2], there are still some unknowns about
> Neutron server side. Monty Taylor is trying to address necessary (if any)
> changes [3].
> 
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of
> it. Some of them are just documentation and docstrings, but there are a
> lot of places, where variables are tangled: defined in DB, used in server,
> accessed by client. Most of places are just internal usages. The only
> thing where I've found 'public' information about tenants is 'help'
> command in neutron client.
> 
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller
> amount of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to
> start with renaming db columns. It affects a lot of places, so when
> finished should significantly lower number of remained "tenants".
> 3. Deal with all other places.
> 
> Pros:
> - variable names unification in OpenStack code base. Someone needs to
> start this job.
> - one way to describe the same thing, instead of: tenant/account/project.
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
> 
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of
> patchsets to be reviewed.
> 
> What do you think about this? About proposed way of dealing with all 
> changes?
> Is this change necessary?
> Did I forget about something?
> 
> I'll be grateful for any kind of feedback.
> 
> Thanks,
>  Dariusz Smigiel (dasm)
>  Intel Technology Poland
> 
> [1] 
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
> [2]
> 
> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> [3] https://bugs.launchpad.net/neutron/+bug/1503428
> [4]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> [5]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> [6]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Fox, Kevin M]

Somewhat off topic, but:

Yeah, some of us ops still use "tenant" when talking to users because tenant 
prompts a "whats that mean" question from users, and then we get a chance to 
explain it.

Users each have their own definition of "project", and when they see project 
they think they understand it without asking, leading to misunderstandings... :/

+1 for consistency amongst all openstack projects though.

Thanks,
Kevin

From: Kevin Benton [blak...@gmail.com]
Sent: Friday, December 04, 2015 10:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

>Do you mean OpenStack developers, OpenStack customers, or OpenStack code?

All of them. Lots of us still say 'tenant' because that's what it was for quite 
a while. However, with keystone and the other projects referring to 'projects' 
which have 'project_ids', it creates inconsistency when Neutron is still based 
on 'tenant_id' (e.g. "does tenant_id mean user_id or project_id?").

>I'm not sure what you mean here.

Neutron is inconsistent with openstack now. We can't claim we are striving for 
consistency when using the term 'tenant', which is what you were implying with 
the reference to the rest of the networking world.

>Dariusz asked for feedback, and I believe it's valid and useful for me to give 
>my intuitive feedback without having to read up on the history first.

It wasn't just the history, it's the whole justification for the move. I can 
definitely see why you would be against it though if you thought it was for no 
reason.


>and noted a couple of points:

>1. The text here twice says "multi-tenant isolation", not "multi-project
isolation".

>2. This whole renaming proposal apparently stems from an internal
confusion in keystone?

None of this matters. It was decided a long time ago to use 'project' and the 
other projects have switched.


On Fri, Dec 4, 2015 at 10:23 AM, Neil Jerram 
mailto:neil.jer...@metaswitch.com>> wrote:
On 04/12/15 18:03, Kevin Benton wrote:
> >The whole world says 'tenant' for the 'tenant' concept, particularly
> in the context of networking.  Changing to a different term is just
> silly.
>
> Except for the rest of OpenStack.

Do you mean OpenStack developers, OpenStack customers, or OpenStack code?

OpenStack developers mostly say 'tenant', I'd say from my following of
the ML.

All the OpenStack users/operators/customers that I've interacted with,
say 'tenant'.

As far as code is concerned, I'm fine with any initiative to align the
Neutron code better with other OpenStack code - but only so long as this
is change that doesn't cause pain and loss of back-compatibility.  Even
the merge pain from this change may be substantial, let alone that from
API changes.

> Consistency is the one argument we can't use as a reason not to switch
> to project.

I'm not sure what you mean here.

> Please read the blueprint and the email it links
> to: https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project

Dariusz asked for feedback, and I believe it's valid and useful for me
to give my intuitive feedback without having to read up on the history
first.

Also it seems likely to me that the fact that this work hasn't happened,
for two years, is a reflection of most people not really wanting it.  I
thought it might be helpful to get that out in the open.

That said, I did look at some of the history -
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html:

> +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.

and noted a couple of points:

1. The text here twice says "multi-tenant isolation", not "multi-project
isolation".

2. This whole renaming proposal apparently stems from an internal
confusion in keystone?

Regards,
Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Kevin Benton]

>Do you mean OpenStack developers, OpenStack customers, or OpenStack code?

All of them. Lots of us still say 'tenant' because that's what it was for
quite a while. However, with keystone and the other projects referring to
'projects' which have 'project_ids', it creates inconsistency when Neutron
is still based on 'tenant_id' (e.g. "does tenant_id mean user_id or
project_id?").

>I'm not sure what you mean here.

Neutron is inconsistent with openstack now. We can't claim we are striving
for consistency when using the term 'tenant', which is what you were
implying with the reference to the rest of the networking world.

>Dariusz asked for feedback, and I believe it's valid and useful for me to
give my intuitive feedback without having to read up on the history first.

It wasn't just the history, it's the whole justification for the move. I
can definitely see why you would be against it though if you thought it was
for no reason.


>and noted a couple of points:

>1. The text here twice says "multi-tenant isolation", not "multi-project
isolation".

>2. This whole renaming proposal apparently stems from an internal
confusion in keystone?

None of this matters. It was decided a long time ago to use 'project' and
the other projects have switched.


On Fri, Dec 4, 2015 at 10:23 AM, Neil Jerram 
wrote:

> On 04/12/15 18:03, Kevin Benton wrote:
> > >The whole world says 'tenant' for the 'tenant' concept, particularly
> > in the context of networking.  Changing to a different term is just
> > silly.
> >
> > Except for the rest of OpenStack.
>
> Do you mean OpenStack developers, OpenStack customers, or OpenStack code?
>
> OpenStack developers mostly say 'tenant', I'd say from my following of
> the ML.
>
> All the OpenStack users/operators/customers that I've interacted with,
> say 'tenant'.
>
> As far as code is concerned, I'm fine with any initiative to align the
> Neutron code better with other OpenStack code - but only so long as this
> is change that doesn't cause pain and loss of back-compatibility.  Even
> the merge pain from this change may be substantial, let alone that from
> API changes.
>
> > Consistency is the one argument we can't use as a reason not to switch
> > to project.
>
> I'm not sure what you mean here.
>
> > Please read the blueprint and the email it links
> > to:
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
>
> Dariusz asked for feedback, and I believe it's valid and useful for me
> to give my intuitive feedback without having to read up on the history
> first.
>
> Also it seems likely to me that the fact that this work hasn't happened,
> for two years, is a reflection of most people not really wanting it.  I
> thought it might be helpful to get that out in the open.
>
> That said, I did look at some of the history -
>
> https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html
> :
>
> > +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.
>
> and noted a couple of points:
>
> 1. The text here twice says "multi-tenant isolation", not "multi-project
> isolation".
>
> 2. This whole renaming proposal apparently stems from an internal
> confusion in keystone?
>
> Regards,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Neil Jerram]

On 04/12/15 18:03, Kevin Benton wrote:
> >The whole world says 'tenant' for the 'tenant' concept, particularly
> in the context of networking.  Changing to a different term is just
> silly.
>
> Except for the rest of OpenStack.

Do you mean OpenStack developers, OpenStack customers, or OpenStack code?

OpenStack developers mostly say 'tenant', I'd say from my following of
the ML.

All the OpenStack users/operators/customers that I've interacted with,
say 'tenant'.

As far as code is concerned, I'm fine with any initiative to align the
Neutron code better with other OpenStack code - but only so long as this
is change that doesn't cause pain and loss of back-compatibility.  Even
the merge pain from this change may be substantial, let alone that from
API changes.

> Consistency is the one argument we can't use as a reason not to switch
> to project.

I'm not sure what you mean here.

> Please read the blueprint and the email it links
> to: https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project

Dariusz asked for feedback, and I believe it's valid and useful for me
to give my intuitive feedback without having to read up on the history
first.

Also it seems likely to me that the fact that this work hasn't happened,
for two years, is a reflection of most people not really wanting it.  I
thought it might be helpful to get that out in the open.

That said, I did look at some of the history -
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html:

> +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.

and noted a couple of points:

1. The text here twice says "multi-tenant isolation", not "multi-project
isolation".

2. This whole renaming proposal apparently stems from an internal
confusion in keystone?

Regards,
Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Kevin Benton]

So obviously the stuff in the client can be updated since most of that is
user-facing. However, on the server side maybe we can start out by keeping
all of the internal code and DB tables the same. Then all we need to worry
about is the API translation code to start.

Once our public-facing stuff is done, we can just start the transition to
project_id internally at our own pace and in much less invasive chunks.

On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz  wrote:

> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> [6], and probably forever. It will stay at least four releases, but we need
> to decide, how to conquer problem of renaming...
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but
> unfortunately, no one finished it. Although Keystone V3 API is already
> supported in Neutron client [2], there are still some unknowns about
> Neutron server side. Monty Taylor is trying to address necessary (if any)
> changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of
> it. Some of them are just documentation and docstrings, but there are a lot
> of places, where variables are tangled: defined in DB, used in server,
> accessed by client. Most of places are just internal usages. The only thing
> where I've found 'public' information about tenants is 'help' command in
> neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller
> amount of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to
> start with renaming db columns. It affects a lot of places, so when
> finished should significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to
> start this job.
> - one way to describe the same thing, instead of: tenant/account/project.
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all
> changes?
> Is this change necessary?
> Did I forget about something?
>
> I'll be grateful for any kind of feedback.
>
> Thanks,
>  Dariusz Smigiel (dasm)
>  Intel Technology Poland
>
> [1]
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
> [2]
> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> [3] https://bugs.launchpad.net/neutron/+bug/1503428
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> [5]
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> [6]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Kevin Benton]

>The whole world says 'tenant' for the 'tenant' concept, particularly in
the context of networking.  Changing to a different term is just silly.

Except for the rest of OpenStack. Consistency is the one argument we can't
use as a reason not to switch to project. Please read the blueprint and the
email it links to:
https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project


On Fri, Dec 4, 2015 at 8:46 AM, Neil Jerram 
wrote:

> I'm new to this discussion, but you did ask for any feedback, so ...
>
> On 03/12/15 18:29, Smigiel, Dariusz wrote:
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> [6], and probably forever. It will stay at least four releases, but we need
> to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
> to 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013 [4][5]
> but unfortunately, no one finished it. Although Keystone V3 API is already
> supported in Neutron client [2], there are still some unknowns about
> Neutron server side. Monty Taylor is trying to address necessary (if any)
> changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has 3021
> of it. Some of them are just documentation and docstrings, but there are a
> lot of places, where variables are tangled: defined in DB, used in server,
> accessed by client. Most of places are just internal usages. The only thing
> where I've found 'public' information about tenants is 'help' command in
> neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> amount of code to look through, update all places and be successful :)
> > 2. Bigger challenge will be to change server side code. I'd suggest to
> start with renaming db columns. It affects a lot of places, so when
> finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> start this job.
> > - one way to describe the same thing, instead of:
> tenant/account/project. Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot of
> patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all
> changes?
> > Is this change necessary?
>
> My intuition is that we should just not do this change.  The whole world
> says 'tenant' for the 'tenant' concept, particularly in the context of
> networking.  Changing to a different term is just silly.
>
> But I haven't looked into the history.  Perhaps there's some reason we
> need to anyway.
>
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Neil Jerram]

I'm new to this discussion, but you did ask for any feedback, so ...

On 03/12/15 18:29, Smigiel, Dariusz wrote:
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
> and probably forever. It will stay at least four releases, but we need to 
> decide, how to conquer problem of renaming... 
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but 
> unfortunately, no one finished it. Although Keystone V3 API is already 
> supported in Neutron client [2], there are still some unknowns about Neutron 
> server side. Monty Taylor is trying to address necessary (if any) changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
> Some of them are just documentation and docstrings, but there are a lot of 
> places, where variables are tangled: defined in DB, used in server, accessed 
> by client. Most of places are just internal usages. The only thing where I've 
> found 'public' information about tenants is 'help' command in neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller amount 
> of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to start 
> with renaming db columns. It affects a lot of places, so when finished should 
> significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to start 
> this job.
> - one way to describe the same thing, instead of: tenant/account/project. 
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of 
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all changes?
> Is this change necessary?

My intuition is that we should just not do this change.  The whole world
says 'tenant' for the 'tenant' concept, particularly in the context of
networking.  Changing to a different term is just silly.

But I haven't looked into the history.  Perhaps there's some reason we
need to anyway.

Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Rename tenant to project: discussion

[Smigiel, Dariusz]

Hey Neutrinos (thanks armax for this word :),
Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
and probably forever. It will stay at least four releases, but we need to 
decide, how to conquer problem of renaming... 
And more important: consider if it's a problem for Neutron?

I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
'project', and trying to find out all the details.
First attempt to solve this problem was raised in November 2013 [4][5] but 
unfortunately, no one finished it. Although Keystone V3 API is already 
supported in Neutron client [2], there are still some unknowns about Neutron 
server side. Monty Taylor is trying to address necessary (if any) changes [3].

Findings:
I've focused on two projects: python-neutronclient and neutron.
grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
Some of them are just documentation and docstrings, but there are a lot of 
places, where variables are tangled: defined in DB, used in server, accessed by 
client. Most of places are just internal usages. The only thing where I've 
found 'public' information about tenants is 'help' command in neutron client.

Suggested plan for conquer:
1. First step would be to deal with neutronclient. It's much smaller amount of 
code to look through, update all places and be successful :)
2. Bigger challenge will be to change server side code. I'd suggest to start 
with renaming db columns. It affects a lot of places, so when finished should 
significantly lower number of remained "tenants".
3. Deal with all other places.

Pros:
- variable names unification in OpenStack code base. Someone needs to start 
this job.
- one way to describe the same thing, instead of: tenant/account/project. 
Helpful, especially for newcomers.
- alignment with Keystone V3 API

Cons:
- A. Lot. Of. Work.
- dealing with DB migrations
- about 2-4 weeks of work for every part of code. Additional, a lot of 
patchsets to be reviewed.

What do you think about this? About proposed way of dealing with all changes?
Is this change necessary?
Did I forget about something?

I'll be grateful for any kind of feedback.

Thanks,
 Dariusz Smigiel (dasm)
 Intel Technology Poland

[1] https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
[2] 
https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
[3] https://bugs.launchpad.net/neutron/+bug/1503428
[4] http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
[5] http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
[6] http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev