<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 December 2015 at 10:02, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div></blockquote><div><br></div><div>This plan is sensible, and kudos to <span style="font-size:12.8px">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 </span>a mechanical search and replace effort. We gotta be extra careful to support both terms in the process.</div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">To sum it up I see the following steps:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">2) Start from the client to allow to handle both project_id and tenant_id.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><br></div><div><span style="font-size:12.8px">3) Tackle the data model.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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). </span><span style="font-size:12.8px">The sooner we start here, the sooner we catch and fix breakages</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">4) Tackle the codebase sweep.</span></div><div><span style="font-size:12.8px"><br></span></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <span dir="ltr"><<a href="mailto:dariusz.smigiel@intel.com" target="_blank">dariusz.smigiel@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hey Neutrinos (thanks armax for this word :),<br>
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...<br>
And more important: consider if it's a problem for Neutron?<br>
<br>
I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 'project', and trying to find out all the details.<br>
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].<br>
<br>
Findings:<br>
I've focused on two projects: python-neutronclient and neutron.<br>
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.<br>
<br>
Suggested plan for conquer:<br>
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 :)<br>
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".<br>
3. Deal with all other places.<br>
<br>
Pros:<br>
- variable names unification in OpenStack code base. Someone needs to start this job.<br>
- one way to describe the same thing, instead of: tenant/account/project. Helpful, especially for newcomers.<br>
- alignment with Keystone V3 API<br>
<br>
Cons:<br>
- A. Lot. Of. Work.<br>
- dealing with DB migrations<br>
- about 2-4 weeks of work for every part of code. Additional, a lot of patchsets to be reviewed.<br>
<br>
What do you think about this? About proposed way of dealing with all changes?<br>
Is this change necessary?<br>
Did I forget about something?<br>
<br>
I'll be grateful for any kind of feedback.<br>
<br>
Thanks,<br>
 Dariusz Smigiel (dasm)<br>
 Intel Technology Poland<br>
<br>
[1] <a href="https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project</a><br>
[2] <a href="https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support</a><br>
[3] <a href="https://bugs.launchpad.net/neutron/+bug/1503428" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1503428</a><br>
[4] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html</a><br>
[5] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html</a><br>
[6] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class=""><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br><br></blockquote></div></div></div>