<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2015, at 12:40 PM, Kyle Mestery <<a href="mailto:mestery@mestery.com" class="">mestery@mestery.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:gessau@gmail.com" target="_blank" class="">gessau@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;"><span class="">Kevin Benton <<a href="mailto:blak111@gmail.com" class="">blak111@gmail.com</a>> wrote:<br class="">> So obviously the stuff in the client can be updated since most of that is<br class="">> user-facing. However, on the server side maybe we can start out by keeping all<br class="">> of the internal code and DB tables the same. Then all we need to worry about<br class="">> is the API translation code to start.<br class="">><br class="">> Once our public-facing stuff is done, we can just start the transition to<br class="">> project_id internally at our own pace and in much less invasive chunks.<br class=""><br class=""></span>I agree with Kevin's suggestion.<br class=""><span class="im HOEnZb"><br class=""></span></blockquote><div class=""><br class=""></div><div class="">++, and this is what Salvatore has previously suggested as well.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>There was general consensus around this at the last neutron meeting, too.</div><div><br class=""></div><div>And one thing missing from your analysis is subprojects that import neutron. Many will be referencing tenant or tenant_id in methods, models, or dicts, and though those are “internal”, providing backwards compatibility would be a sane thing to consider.</div><div><br class=""></div><div>Thanks,</div><div>dogu</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></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;"><span class="im HOEnZb">> On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <<a href="mailto:dariusz.smigiel@intel.com" class="">dariusz.smigiel@intel.com</a><br class=""></span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:dariusz.smigiel@intel.com" class="">dariusz.smigiel@intel.com</a>>> wrote:<br class="">><br class="">> Hey Neutrinos (thanks armax for this word :),<br class="">> Keystone is planning to deprecate V2 API (again :). This time in Mitaka<br class="">> [6], and probably forever. It will stay at least four releases, but we<br class="">> need to decide, how to conquer problem of renaming...<br class="">> And more important: consider if it's a problem for Neutron?<br class="">><br class="">> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to<br class="">> 'project', and trying to find out all the details.<br class="">> First attempt to solve this problem was raised in November 2013 [4][5] but<br class="">> unfortunately, no one finished it. Although Keystone V3 API is already<br class="">> supported in Neutron client [2], there are still some unknowns about<br class="">> Neutron server side. Monty Taylor is trying to address necessary (if any)<br class="">> changes [3].<br class="">><br class="">> Findings:<br class="">> I've focused on two projects: python-neutronclient and neutron.<br class="">> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of<br class="">> it. Some of them are just documentation and docstrings, but there are a<br class="">> lot of places, where variables are tangled: defined in DB, used in server,<br class="">> accessed by client. Most of places are just internal usages. The only<br class="">> thing where I've found 'public' information about tenants is 'help'<br class="">> command in neutron client.<br class="">><br class="">> Suggested plan for conquer:<br class="">> 1. First step would be to deal with neutronclient. It's much smaller<br class="">> amount of code to look through, update all places and be successful :)<br class="">> 2. Bigger challenge will be to change server side code. I'd suggest to<br class="">> start with renaming db columns. It affects a lot of places, so when<br class="">> finished should significantly lower number of remained "tenants".<br class="">> 3. Deal with all other places.<br class="">><br class="">> Pros:<br class="">> - variable names unification in OpenStack code base. Someone needs to<br class="">> start this job.<br class="">> - one way to describe the same thing, instead of: tenant/account/project.<br class="">> Helpful, especially for newcomers.<br class="">> - alignment with Keystone V3 API<br class="">><br class="">> Cons:<br class="">> - A. Lot. Of. Work.<br class="">> - dealing with DB migrations<br class="">> - about 2-4 weeks of work for every part of code. Additional, a lot of<br class="">> patchsets to be reviewed.<br class="">><br class="">> What do you think about this? About proposed way of dealing with all changes?<br class="">> Is this change necessary?<br class="">> Did I forget about something?<br class="">><br class="">> I'll be grateful for any kind of feedback.<br class="">><br class="">> Thanks,<br class="">> Dariusz Smigiel (dasm)<br class="">> Intel Technology Poland<br class="">><br class="">> [1]<span class="Apple-converted-space"> </span><a href="https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project" rel="noreferrer" target="_blank" class="">https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project</a><br class="">> [2]<br class="">> <a href="https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support" rel="noreferrer" target="_blank" class="">https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support</a><br class="">> [3]<span class="Apple-converted-space"> </span><a href="https://bugs.launchpad.net/neutron/+bug/1503428" rel="noreferrer" target="_blank" class="">https://bugs.launchpad.net/neutron/+bug/1503428</a><br class="">> [4]<br class="">> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html</a><br class="">> [5]<br class="">> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html</a><br class="">> [6]<br class="">> <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm</a><br class="">><br class=""><br class=""><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></div></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">__________________________________________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">OpenStack Development Mailing List (not for usage questions)</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Unsubscribe:<span class="Apple-converted-space"> </span></span><a href="mailto:OpenStack-dev-request@lists.openstack.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">OpenStack-dev-request@lists.openstack.org</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">?subject:unsubscribe</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br class=""></body></html>