Open Stack

> On Jul 15, 2016, at 11:33 AM, Neil Jerram <neil at tigera.io> 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 <HenryG at gessau.net <mailto:HenryG at gessau.net>> wrote:
> Henry Gessau <HenryG at gessau.net <mailto: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 <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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?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: 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/18683cb5/attachment.html>