Open Stack

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/080816.htm
>
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> 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
>