Open Stack

>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.Jerram at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151204/5b9508b2/attachment.html>