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 <blak...@gmail.com > > <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, 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 > > <dariusz.smig...@intel.com <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/08081 > > 6.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
