Open Stack

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 <smigiel.dariusz at gmail.com> wrote:
> 
>> 
>> On Jul 15, 2016, at 11:33 AM, Neil Jerram <neil at tigera.io <mailto: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 <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 <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 <mailto:OpenStack-dev-request at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160725/214a2aa5/attachment.html>