>The whole world says 'tenant' for the 'tenant' concept, particularly in the context of networking. Changing to a different term is just silly.
Except for the rest of OpenStack. Consistency is the one argument we can't use as a reason not to switch to project. Please read the blueprint and the email it links to: https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project On Fri, Dec 4, 2015 at 8:46 AM, Neil Jerram <neil.jer...@metaswitch.com> wrote: > I'm new to this discussion, but you did ask for any feedback, so ... > > On 03/12/15 18:29, Smigiel, Dariusz 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? > > My intuition is that we should just not do this change. The whole world > says 'tenant' for the 'tenant' concept, particularly in the context of > networking. Changing to a different term is just silly. > > But I haven't looked into the history. Perhaps there's some reason we > need to anyway. > > Neil > > > __________________________________________________________________________ > 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 > -- Kevin Benton
__________________________________________________________________________ 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
