neutron requests missing tenant_id in certain keystone configurations

[Kevin Benton]

None of the Neutron object create requests include the tenant_id that should own the object. This is fine when the tenant_id is explicitly set in the keystone context passed to Neutron because it derives the tenant_id from that. However, if another keystone authentication method is used that only sets the token, the tenant_id won't be present and Neutron will give the following error to create requests:

"Running without keystone AuthN requires that tenant_id is specified"

[Lin Hua Cheng (lin-hua-cheng)]

https://review.openstack.org/#/c/133884/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/133884
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=b29a5eff1b62b418159aa4689adeac8f396e56c9
Submitter: Jenkins
Branch: master

commit b29a5eff1b62b418159aa4689adeac8f396e56c9
Author: Kevin Benton <email address hidden>
Date: Fri Dec 5 11:42:13 2014 -0800

    Provide tenant_id in Neutron create requests

    Include the tenant_id explicitly in the Neutron object creation
    requests rather than assuming that all of the information can
    be derived from Keystone. This fixes deployments that only pass
    tokens to Neutron.

    Closes-Bug: #1400418
    Change-Id: I10d50c202c7fd156455a97c6a5451225154ae0bc

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/143260

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/143261

[Akihiro Motoki (amotoki)]

Although I could not chime in the review of the master branch, I wonder why tenant_id always needs to be passed to Neutron when creating a Neutron resource. I think POST without tenant_id is very common case in OpenStack REST API, so why we need to treat Neutron specially. Is it a common practice across all OpenStack projects? If not, it is not a Horizon problem but a Neutron issue. Could you clarify the condition where this bug occurs more? Is it a special case for Neutron? If so, we should consider it is fixed in Neutron and only if it cannot be fixed in neutron we should add a workaround in Horizon.

[Kevin Benton (kevinbenton)]

This happens when using 'noauth' on the Neutron side.

[Akihiro Motoki (amotoki)]

Horizon requires keystone. I am not sure we need to support a case where keystone is enabled but neutron does not use keystone.
There are several services which support to skip keystone auth (such as Glance). It is not specific to Neutron.
I am just afraid we are going to ad-hoc way...

[Kevin Benton (kevinbenton)]

If horizon is the only public facing component, neutron can have keystone disabled since it's in a trusted network.

[Dave Walker (davewalker)]

@Kevin, have you been able to progress this with Neutron core?

[Kevin Benton (kevinbenton)]

It ultimately depends on if we want Horizon to support deployments where Keystone is not enabled on one of the services. Akihiro mentioned Glance has a deployment like that, is it okay to do the same thing for Neutron?

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kevin Benton (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/143260
Reason: no interest in supporting limited keystone environments.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kevin Benton (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/143261
Reason: no interest in supporting limited keystone environments.