Open Stack

On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau <gessau at gmail.com> wrote:

> 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.
>
>
++, and this is what Salvatore has previously suggested as well.


> > 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
> >
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151204/d09ce7ed/attachment.html>