Kevin Benton <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. > 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/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
