Server/ServerGroup creation on especified tenant doesn't works as expected

[Cristian]

Nova API docs specify the parameter tenant_id for the creation of servers. (http://developer.openstack.org/api-ref-compute-v2.1.html#createServer)

I tried to create a server on a diferent tenant, with admin credentials and loged with admin perspective. The request is succesfully executed, but the new server is created in the logged tenant, not the especified tenant.

ServerGroup creation has the same behaviour.

Istalled versions:
openstack-nova-api.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-cert.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-common.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-compute.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-conductor.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-console.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-novncproxy.noarch 1:12.0.1-1.el7 @openstack-liberty
openstack-nova-scheduler.noarch 1:12.0.1-1.el7 @openstack-liberty
python-nova.noarch 1:12.0.1-1.el7 @openstack-liberty
python-novaclient.noarch 1:2.30.1-1.el7 @openstack-liberty

Requests & responses:

mar 01, 2016 10:52:51 AM org.glassfish.jersey.filter.LoggingFilter log
INFORMACIÓN: 1 * Sending client request on thread pool-5-thread-1
1 > POST http://10.13.111.56:8774/v2/4b216910ea1c4701a629d98fd8600300/servers
1 > Accept: application/json
1 > Content-Type: application/json
1 > User-Agent: OpenStack4j / OpenStack Client
1 > X-Auth-Token: 041b5843231449eba1b99b305bacf1b2
{
  "server" : {
    "name" : "vm1",
    "imageRef" : "dd62a5c7-68c1-4f37-ba73-f55536a50b97",
    "flavorRef" : "2",
    "availability_zone" : "nova",
    "networks" : [ {
      "uuid" : "a7489c95-71a4-499d-93b7-b0ae456a3361"
    } ],
    "tenant_id" : "2756c66a63cd4165af9f01d348449cbb"
  },
  "os:scheduler_hints" : {
    "group" : "d96f6c5a-27e1-4dfb-9c2c-8e79e81ea6f9"
  }
}

mar 01, 2016 10:52:51 AM org.glassfish.jersey.filter.LoggingFilter log
INFORMACIÓN: 2 * Client response received on thread pool-5-thread-1
2 < 202
2 < Connection: keep-alive
2 < Content-Length: 440
2 < Content-Type: application/json
2 < Date: Tue, 01 Mar 2016 09:52:53 GMT
2 < Location: http://10.13.111.56:8774/v2/4b216910ea1c4701a629d98fd8600300/servers/8c4a8657-7968-4915-af29-fad1ad2957b7
2 < X-Compute-Request-Id: req-ee2fa864-579d-41ad-9357-cb55d665ef91
{"server": {"security_groups": [{"name": "default"}], "OS-DCF:diskConfig": "MANUAL", "id": "8c4a8657-7968-4915-af29-fad1ad2957b7", "links": [{"href": "http://10.13.111.56:8774/v2/4b216910ea1c4701a629d98fd8600300/servers/8c4a8657-7968-4915-af29-fad1ad2957b7", "rel": "self"}, {"href": "http://10.13.111.56:8774/4b216910ea1c4701a629d98fd8600300/servers/8c4a8657-7968-4915-af29-fad1ad2957b7", "rel": "bookmark"}], "adminPass": "QEN67WN9Dgjh"}}

mar 01, 2016 10:52:51 AM org.glassfish.jersey.filter.LoggingFilter log
INFORMACIÓN: 1 * Sending client request on thread pool-5-thread-1
1 > GET http://10.13.111.56:8774/v2/4b216910ea1c4701a629d98fd8600300/servers/8c4a8657-7968-4915-af29-fad1ad2957b7
1 > Accept: application/json
1 > User-Agent: OpenStack4j / OpenStack Client
1 > X-Auth-Token: 041b5843231449eba1b99b305bacf1b2

mar 01, 2016 10:52:51 AM org.glassfish.jersey.filter.LoggingFilter log
INFORMACIÓN: 2 * Client response received on thread pool-5-thread-1
2 < 200
2 < Connection: keep-alive
2 < Content-Length: 1461
2 < Content-Type: application/json
2 < Date: Tue, 01 Mar 2016 09:52:53 GMT
2 < X-Compute-Request-Id: req-5de6a7e1-ef84-4d67-ba05-b1f8772d82bb
{"server": {"status": "BUILD", "updated": "2016-03-01T09:52:53Z", "hostId": "", "OS-EXT-SRV-ATTR:host": null, "addresses": {}, "links": [{"href": "http://10.13.111.56:8774/v2/4b216910ea1c4701a629d98fd8600300/servers/8c4a8657-7968-4915-af29-fad1ad2957b7", "rel": "self"}, {"href": "http://10.13.111.56:8774/4b216910ea1c4701a629d98fd8600300/servers/8c4a8657-7968-4915-af29-fad1ad2957b7", "rel": "bookmark"}], "key_name": null, "image": {"id": "dd62a5c7-68c1-4f37-ba73-f55536a50b97", "links": [{"href": "http://10.13.111.56:8774/4b216910ea1c4701a629d98fd8600300/images/dd62a5c7-68c1-4f37-ba73-f55536a50b97", "rel": "bookmark"}]}, "OS-EXT-STS:task_state": "scheduling", "OS-EXT-STS:vm_state": "building", "OS-EXT-SRV-ATTR:instance_name": "instance-0000001c", "OS-SRV-USG:launched_at": null, "OS-EXT-SRV-ATTR:hypervisor_hostname": null, "flavor": {"id": "2", "links": [{"href": "http://10.13.111.56:8774/4b216910ea1c4701a629d98fd8600300/flavors/2", "rel": "bookmark"}]}, "id": "8c4a8657-7968-4915-af29-fad1ad2957b7", "OS-SRV-USG:terminated_at": null, "OS-EXT-AZ:availability_zone": "nova", "user_id": "143b5a5f39b444999cc90e6d35506bf3", "name": "vm1", "created": "2016-03-01T09:52:53Z", "tenant_id": "4b216910ea1c4701a629d98fd8600300", "OS-DCF:diskConfig": "MANUAL", "os-extended-volumes:volumes_attached": [], "accessIPv4": "", "accessIPv6": "", "progress": 0, "OS-EXT-STS:power_state": 0, "config_drive": "", }}

[Markus Zoeller (markus_z) (mzoeller)]

@Cristian:

The "tenant_id" is part of the URI and *not* part of the parameters in
the request body. The value "URI" in the "Style" column explains that.
It's especially good to see when querying server details [1]:

    GET /v2.1/​{tenant_id}​/servers/​{server_id}​

    Parameter Style
    tenant_id URI
    server_id URI

Your POST call to create a server provides the "tenant_id" in its URI:

    http://10.13.111.56:8774/v2/4b216910ea1c4701a629d98fd8600300/servers

    tenant_id = 4b216910ea1c4701a629d98fd8600300

The other "tenant_id" you provide in the request body is silently
ignored.

Your call to get the server details shows that it correctly uses the
"tenant_id" you provided in the URI of the POST call:

    "tenant_id": "4b216910ea1c4701a629d98fd8600300"

The API behaves as expected and documented, which means I close this
bug report as "invalid". If you disagree, please reopen the bug and
provide a reasoning.

References:
[1] http://developer.openstack.org/api-ref-compute-v2.1.html#showServer