Open Stack

Kevin Benton <blak111 at 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.smigiel at intel.com
> <mailto:dariusz.smigiel at 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
>