> On Dec 4, 2015, at 12:40 PM, Kyle Mestery <mest...@mestery.com> wrote: > > On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau <ges...@gmail.com > <mailto:ges...@gmail.com>> wrote: > 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. > > 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 > > <dariusz.smig...@intel.com <mailto:dariusz.smig...@intel.com> > > <mailto: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 > > <https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project> > > [2] > > > > https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support > > > > <https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support> > > [3] https://bugs.launchpad.net/neutron/+bug/1503428 > > <https://bugs.launchpad.net/neutron/+bug/1503428> > > [4] > > > > http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html > > > > <http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html> > > [5] > > > > http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html > > > > <http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html> > > [6] > > > > http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm > > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
