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 [2] http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html [3] https://review.openstack.org/335786 [4] https://review.openstack.org/244680 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
