Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Darek Śmigiel]

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 

[2] https://review.openstack.org/#/q/topic:bp/keystone-v3+status:open 


> On Jul 15, 2016, at 12:50 PM, Darek Śmigiel  wrote:
> 
>> 
>> On Jul 15, 2016, at 11:33 AM, Neil Jerram > > 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 > > wrote:
>> Henry Gessau mailto:hen...@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-tenant2pro

Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Darek Śmigiel]

> On Jul 15, 2016, at 11:33 AM, Neil Jerram  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  > wrote:
> Henry Gessau mailto:hen...@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-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj

Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Neil Jerram]

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  wrote:

> Henry Gessau  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

Henry Gessau  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev