<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 Jul 15, 2016, at 11:33 AM, Neil Jerram <<a href="mailto:neil@tigera.io" class="">neil@tigera.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">I've put my name against networking-calico, but I believe it's a no-op for me at this stage of the tenant->project transition.  The occurrences of 'tenant' in networking-calico's code are:<br class=""><br class="">./networking_calico/plugins/calico/plugin.py:45:        <a href="http://log.info" class="">LOG.info</a>("Forcing ML2 tenant_network_types to 'local'")<br class="">./networking_calico/plugins/calico/plugin.py:46:        cfg.CONF.set_override('tenant_network_types', ['local'], group='ml2')<br class="">./networking_calico/agent/dhcp_agent.py:213:          'tenant_id': ? }<br class="">./networking_calico/agent/dhcp_agent.py:298:                                  "tenant_id": "calico",<br class=""><br class=""></div>So it's just:<br class=""></div>- the ML2 'tenant_network_types' config setting name<br class=""></div>- the 'tenant_id' key used in neutron.agent.linux.dhcp.NetModel.<br class=""><br class=""></div>I guess those will be transitioned in due course.  Am I right in thinking that there's no action for networking-calico right now, or do you think I've missed something?<br class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>Hey Neil,</div><div>Thank you for adding calico.</div><div><br class=""></div><div>It seems that you’re right. Probably there is no required work for networking-calico, but good to have all possible projects gathered in one place.</div><div>Couple of other subprojects, which do not write to Neutron DB, also are not changed.</div><div><br class=""></div><div>Darek</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Thanks,<br class=""></div>     Neil<br class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Jul 14, 2016 at 9:32 PM Henry Gessau <<a href="mailto:HenryG@gessau.net" class="">HenryG@gessau.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Henry Gessau <<a href="mailto:HenryG@gessau.net" target="_blank" class="">HenryG@gessau.net</a>> wrote:<br class="">
> In accordance with the Blueprint [1] and the spec [2], we are in the process<br class="">
> of deprecating the use of the term 'tenant' in favor of 'project'.<br class="">
><br class="">
> The code change [3] with the biggest impact on Neutron developers is currently<br class="">
> out for review and will merge quite soon (shortly after N-2). This change<br class="">
> renames all 'tenant_id' columns in the database to 'project_id'.<br class="">
><br class="">
> If you have any changes in flight that touch a tenant_id field, you will be<br class="">
> affected. Please familiarize yourself with [3], rebase on it, and comply with<br class="">
> the changes.<br class="">
><br class="">
> One patch known to be affected is [4].<br class="">
><br class="">
> The column rename change has been designed to have minimal impact on the usage<br class="">
> of 'tenant_id' fields. For now 'tenant_id' is still available as a<br class="">
> key/property in resource dicts and objects, and as an attribute in request<br class="">
> contexts.<br class="">
><br class="">
> In the long run (Ocata or beyond) we want to end up with no usages of the term<br class="">
> 'tenant', except in the API for backwards compatibility. Existing usages of<br class="">
> 'tenant' in the codebase will be converted to 'project' on a case-by-case<br class="">
> basis. Although the conversion has not yet commenced, any *new* fields,<br class="">
> arguments, variables, etc. with 'tenant' in the name will no longer be accepted.<br class="">
><br class="">
> [1] <a href="https://blueprints.launchpad.net/neutron/+spec/keystone-v3" rel="noreferrer" target="_blank" class="">https://blueprints.launchpad.net/neutron/+spec/keystone-v3</a><br class="">
> [2]<br class="">
> <a href="http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html" rel="noreferrer" target="_blank" class="">http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html</a><br class="">
> [3] <a href="https://review.openstack.org/335786" rel="noreferrer" target="_blank" class="">https://review.openstack.org/335786</a><br class="">
> [4] <a href="https://review.openstack.org/244680" rel="noreferrer" target="_blank" class="">https://review.openstack.org/244680</a><br class="">
<br class="">
This work also affects repos that integrate with neutron and have tables in<br class="">
the Neutron database. We have started to submit patches for the neutron-fwaas,<br class="">
-lbaas, and -vpnaas repos, and we are keeping track of the progress with an<br class="">
etherpad [5].<br class="">
<br class="">
I have listed all the Neutron Stadium projects there, as well as all the<br class="">
projects that I could find hosted on <a href="http://git.openstack.org/" rel="noreferrer" target="_blank" class="">git.openstack.org</a> that integrate with the<br class="">
Neutron DB. Please help by signing up for a project.<br class="">
<br class="">
If you encounter any problem or issues, please ask us for help. Either reply<br class="">
to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron IRC<br class="">
channel.<br class="">
<br class="">
[5] <a href="https://etherpad.openstack.org/p/neutron-stadium-tenant2project" rel="noreferrer" target="_blank" class="">https://etherpad.openstack.org/p/neutron-stadium-tenant2project</a><br class="">
<br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <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="">
</blockquote></div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>