On 12/04/2015 04:26 PM, Armando M. wrote:
On 4 December 2015 at 10:02, Kevin Benton <[email protected]
<mailto:[email protected]>> 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, seamlessly....something 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
<[email protected] <mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
