<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau <span dir="ltr"><<a href="mailto:gessau@gmail.com" target="_blank">gessau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br>
> So obviously the stuff in the client can be updated since most of that is<br>
> user-facing. However, on the server side maybe we can start out by keeping all<br>
> of the internal code and DB tables the same. Then all we need to worry about<br>
> is the API translation code to start.<br>
><br>
> Once our public-facing stuff is done, we can just start the transition to<br>
> project_id internally at our own pace and in much less invasive chunks.<br>
<br>
</span>I agree with Kevin's suggestion.<br>
<span class="im HOEnZb"><br></span></blockquote><div><br></div><div>++, and this is what Salvatore has previously suggested as well.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">
> On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <<a href="mailto:dariusz.smigiel@intel.com">dariusz.smigiel@intel.com</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:dariusz.smigiel@intel.com">dariusz.smigiel@intel.com</a>>> wrote:<br>
><br>
> Hey Neutrinos (thanks armax for this word :),<br>
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka<br>
> [6], and probably forever. It will stay at least four releases, but we<br>
> 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<br>
> 'project', and trying to find out all the details.<br>
> First attempt to solve this problem was raised in November 2013 [4][5] but<br>
> unfortunately, no one finished it. Although Keystone V3 API is already<br>
> supported in Neutron client [2], there are still some unknowns about<br>
> Neutron server side. Monty Taylor is trying to address necessary (if any)<br>
> 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<br>
> it. Some of them are just documentation and docstrings, but there are a<br>
> lot of places, where variables are tangled: defined in DB, used in server,<br>
> accessed by client. Most of places are just internal usages. The only<br>
> thing where I've found 'public' information about tenants is 'help'<br>
> command in neutron client.<br>
><br>
> Suggested plan for conquer:<br>
> 1. First step would be to deal with neutronclient. It's much smaller<br>
> 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<br>
> start with renaming db columns. It affects a lot of places, so when<br>
> 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<br>
> start this job.<br>
> - one way to describe the same thing, instead of: tenant/account/project.<br>
> 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<br>
> 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]<br>
> <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]<br>
> <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]<br>
> <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]<br>
> <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>
<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>
</div></div></blockquote></div><br></div></div>