Description of problem: When request to create a project (successor of tenant) is sent to Keystone V3 API, with domain_id provided (see link to docs below), it's value is not validated and project is created with invalid association to domain. See documentation https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#create-project-post-projects for example how the project could/should be created - domain_id is also used there. Discovered with openstack-keystone-2013.1.1-1.el6ost. 1) Create project with invalid domain: > localhost:5000 > POST /v3/projects > {"project": > {"domain_id":"invalid-domain", > "name":"projectX", > "enabled":true}} results in: > HTTP - 201 Created > {'project': > {'description': '', > 'domain_id': 'invalid-domain', > 'enabled': True, > 'id': '<PROJECT-ID>', > 'links': { > 'self': 'http://localhost:5000/v3/projects/<PROJECT-ID>'}, > 'name': 'projectX'}} Expected result would be: > HTTP - 404 Not Found > with message in body saying 'Could not find domain: invalid-domain' As that is how other similar requests ends (for ex. creation of Endpoint with invalid service_id).
Reproduced upstream. Problem is a little different than reported: Since the backend is SQL, it complains of a foreign key constraint. {"error": {"message": "Conflict occurred attempting to store project. (1452, 'Cannot add or update a child row: a foreign key constraint fails (`keystone`.`project`, CONSTRAINT `project_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domain` (`id`))')", "code": 409, "title": "Conflict"}}(.venv) What the origianl reporter saw was likely due to running against the KVS backend which did not check the constraint.
This was included in Havana GA https://github.com/openstack/keystone/commit/e692eeadb9d8ae5f4797bcd28d597ee314ea8dff
Tested with: openstack-keystone-2013.2-3.el6ost.noarch Confirmed when sql backend was in use the same error as mentioned in c#2 curl -X POST http://localhost:5000/v3/projects -H "content-type: application/json" -H "X-Auth-Token:$TEST_TOKEN" --data '{"project": {"domain_id":"invalid-domain", "name":"projectX", "enabled":true}}' {"error": {"message": "Conflict occurred attempting to store project. (1452, 'Cannot add or update a child row: a foreign key constraint fails (`keystone`.`project`, CONSTRAINT `project_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domain` (`id`))')", "code": 409, "title": "Conflict"}} Tested with kvs: /etc/keystone/keystone.conf [assignment] driver = keystone.assignment.backends.kvs.Assignment service openstack-keystone stop openstack-db --drop --service keystone openstack-db --init --service keystone service openstack-keystone start No domains exist: curl -X GET http://localhost:5000/v3/domains -H "content-type: application/json" -H "X-Auth-Token:ADMIN" {"domains": [], "links": {"self": "http://localhost:5000/v3/domains", "previous": null, "next": null}} Tested reported post request and got response: curl -X POST http://localhost:5000/v3/projects -H "content-type: application/json" -H "X-Auth-Token:ADMIN" --data '{"project": {"domain_id":"invalid-domain", "name":"projectX", "enabled":true}}' {"project": {"id": "20e03925290544158aeb363374954abe", "enabled": true, "domain_id": "invalid-domain", "links": {"self": "http://localhost:5000/v3/projects/20e03925290544158aeb363374954abe"}, "name": "projectX"}} Checked and it was saved to kvs: curl -X GET http://localhost:5000/v3/projects -H "content-type: application/json" -H "X-Auth-Token:ADMIN" {"links": {"self": "http://localhost:5000/v3/projects", "previous": null, "next": null}, "projects": [{"domain_id": "invalid-domain", "enabled": true, "id": "ba66b34455eb4b47a2efbf676c5577bc", "links": {"self": "http://localhost:5000/v3/projects/ba66b34455eb4b47a2efbf676c5577bc"}, "name": "projectX"}]} Do we still classify this as expected behavior? Posting without "domain_id" will set it to the expected "default" value.
this is expected behaviour, to allow v2 and v3 API interoperability. making as verified
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html