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