Hey Neutrinos, Quick update about Keystone v3 DB migration.
All Stadium projects have necessary changes in review queue. [1] Some of them are already merged, others don’t need to have any updates. But we still have couple more [2] that need to be merged before Neutron change will land. We still have “other projects” [1] without applied changes, but it won’t block final merge. If you have spare time, please look at these changes, and try to merge DB migration ASAP. Thanks, Darek [1] https://etherpad.openstack.org/p/neutron-stadium-tenant2project <https://etherpad.openstack.org/p/neutron-stadium-tenant2project> [2] https://review.openstack.org/#/q/topic:bp/keystone-v3+status:open <https://review.openstack.org/#/q/topic:bp/keystone-v3+status:open> > On Jul 15, 2016, at 12:50 PM, Darek Śmigiel <[email protected]> wrote: > >> >> On Jul 15, 2016, at 11:33 AM, Neil Jerram <[email protected] >> <mailto:[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 >> <http://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] >> <mailto:[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
