Open Stack

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?

Thanks,
     Neil


On Thu, Jul 14, 2016 at 9:32 PM Henry Gessau <HenryG at gessau.net> wrote:

> Henry Gessau <HenryG at gessau.net> 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
> > [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
>
> 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 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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160715/24b7a90e/attachment.html>