Open Stack

Thanks guys for all the feedback.
I'm happy we elaborated some plan for this topic.

-- 
 Dariusz Smigiel
 Intel Technology Poland

> On 12/04/2015 04:26 PM, Armando M. wrote:
> >
> >
> > On 4 December 2015 at 10:02, Kevin Benton <blak111 at gmail.com
> > <mailto: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.
> >
> >
> > This plan is sensible, and kudos to Dariusz to take it on...this is no
> > small feat of engineering and it won't be the effort of a
> > single...we're all here to help. Let me state the obvious and remind
> > that this is not a mechanical search and replace effort. We gotta be
> > extra careful to support both terms in the process.
> >
> > To sum it up I see the following steps:
> >
> > 1) Make or figure out how the server can talk to the v3 API - which is
> > bug 1503428. If Monty is unable to tackle it soon, I am sure he'll be
> > happy to hand it back and Darius, perhaps, can take over
> 
> I will hack on this next week - sorry for the delay so far. I'd love to do a first
> rough pass and then get Darius to look at it and tell me where I'm insane.
> 
> > This will ensure that if for whatever reason v2 gets pulled out
> > tomorrow (not gonna happen, but still), we're not left high and dry.
> > To achieve this, I think we don't invasively need to change tenant id
> > with project id, but only where it's key to get/validate a token.
> 
> ++
> 
> > 2) Start from the client to allow to handle both project_id and tenant_id.
> >
> > The server must be enhanced to be able to convert project_id to
> > tenant_id on the fly. The change should be relatively limited in a few
> > places, like where the request come in. At this time nothing else is
> > required to change in the server.
> 
>  From an auth perspective, keystoneauth will handle both tenant and project
> as auth parameters (and I've got a patch coming to neutronclient to help get
> that all fleshed out too)
> 
>  From the server/api side and client lib side where people are passing in
> tenant_ids to neutron resources because it's important to associate a
> resource with a tenant/project - I think this is a GREAT plan, and thank you
> for doing it this way. As a consumer of your API, I neither want to have to
> change my code to the new version, or write new code using the old version
> (thus perpetuating the move in history)
> 
> I would suggest/request if there is a way (and this might be _terrible_ to
> mark tenant_id in the _docs_ as either hidden or deprecated, so that new
> users don't write new code using it - but of course we should continue to
> accept tenant_id until the end of time because of how much we love our
> users.
> 
> > 3) Tackle the data model.
> >
> > I wonder if we could leverage some sqlalchemy magic to support both
> > project_id and tenant_id in the db logic, seamlessly....something
> > worth investigating (zzzeek may be of help here). The sooner we start
> > here, the sooner we catch and fix breakages
> >
> > 4) Tackle the codebase sweep.
> >
> > As for projects that use neutron and use the internal APIs, I can't
> > see a clean way of handling the bw compat if not by sprinkling
> > decorators that will take the signature of all the affected methods
> > and convert the tenant_id, but we could definitely explore how this would
> look like.
> 
> Yah. That one is going to be yuck. I'm happy to hand people beer ... :)
> >
> >     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/08081
> > 6.htm
> >
> >