On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau <ges...@gmail.com> wrote:
> 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. > > ++, 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 > > <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 >
__________________________________________________________________________ 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