Multiple services with same name and type

[Varun Mittal]

I am working on the current devstack environment.

keystone service-create allows creating multiple services with the same --name and --type.
Is this expected ?

$ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd service-create --name junk --type junk

+-------------+----------------------------------+
| Property | Value |
+-------------+----------------------------------+
| description | |
| enabled | True |
| id | 69a40a334b58433ea7440e6336240611 |
| name | junk |
| type | junk |
+-------------+----------------------------------+

$ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd service-create --name junk --type junk

+-------------+----------------------------------+
| Property | Value |
+-------------+----------------------------------+
| description | |
| enabled | True |
| id | e976635ceb9d4c47bf0763f7b3cdcec9 |
| name | junk |
| type | junk |
+-------------+----------------------------------+

I expected it to fail as the 'user-create' fails with conflict error.

After creating multiple service with same name, keystone endpoint-create fails with the error

$ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd endpoint-create --service junk --publicurl http://junk

Multiple service matches found for 'junk', use an ID to be more specific.

[Lance Bragstad (lbragstad)]

Varun, according to the documentation, the only attribute that is required to create a service is the 'type' attribute and I don't believe it needs to be unique. The 'name' attribute is optional and has no requirement to be unique either. Since it is possible to have multiple services with the same name and type, they can be referenced by their UUID. Even using Keystone V3, 'type' is the only attribute required on service create [1].

[1] https://github.com/openstack/keystone/blob/73ad4036d62b3aa7cf50e11ddf7bee8278bbe4d0/keystone/catalog/schema.py#L56

[Varun Mittal (viral.mutant)]

Hi

In my test environment, both the type and name are required params.

mittal@mittal-virtualbox:~/devstack$ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd service-create
usage: keystone service-create --name <name> --type <type>
                               [--description <service-description>]
keystone service-create: error: argument --name is required

[Varun Mittal (viral.mutant)]

Ok, now I am confused :)

I saw this bug 1259425 which reports the same issue. Not sure where the fix went in. I have marked mine as a Dup of that

Regarding '--name' being reported as mandatory, looks like the keystone-client is throwing that error.

So I tried the curl command directly, and it looks that nothing is mandatory at all. Both name and type are empty and it still works. This was another bug https://bugs.launchpad.net/keystone/+bug/890399 and looks like that was fixed too.

But why it fails for me ?

[root@RHEL1 v2_0]# curl -i -X POST http://keystone:35357/v2.0/OS-KSADM/services -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: jjjj" -d '{"OS-KSADM:service": {"name":"", "type": ""}}'
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 88
Date: Mon, 15 Sep 2014 17:19:23 GMT

{"OS-KSADM:service": {"type": "", "name": "", "id": "b0cf3facb3f940b9b3238291007af57c"}}

[root@RHEL1 v2_0]# curl -i -X POST http://keystone:35357/v2.0/OS-" -H "X-Auth-Token: jjjj" -d '{"OS-KSADM:service": {"name":"", "type": ""}}'ication/json"
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 88
Date: Mon, 15 Sep 2014 17:19:25 GMT

{"OS-KSADM:service": {"type": "", "name": "", "id": "ca6dc107de4d493b9544c703ee553fea"}}

[root@RHEL1 v2_0]# curl -i -X POST http://keystone:35357/v2.0/OS-" -H "X-Auth-Token: jjjj" -d '{"OS-KSADM:service": {"name":"", "type": ""}}'ication/json"
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 88
Date: Mon, 15 Sep 2014 17:19:26 GMT

{"OS-KSADM:service": {"type": "", "name": "", "id": "70640df4c88d43ec8e4e75e0df3023a9"}}

[root@RHEL1 v2_0]# /usr/bin/keystone --debug --os-username mittal --os-tenant-name service --os-token jjjj --os-endpoint http://keystone:35357/v2.0 --os-cacert /etc/keystone/ssl/certs/cacert.pem service-list

+----------------------------------+----------+----------+---------------------------+
| id | name | type | description |
+----------------------------------+----------+----------+---------------------------+
| 70640df4c88d43ec8e4e75e0df3023a9 | | | |
| b0cf3facb3f940b9b3238291007af57c | | | |
| ca6dc107de4d493b9544c703ee553fea | | | |
+----------------------------------+----------+----------+---------------------------+

[Lance Bragstad (lbragstad)]

Varun,

I think 'required' in version 2 means that the attribute is present in the request body. So when you pass {"name":"", "type": ""}, `name` and `type` are both provided, they are just empty strings, but strings none the less. At that point, it becomes a question of validation. Keystone V3 has validation of resource CRUD operations using jsonschema.

I expect that if you modify your curl request like the following (omitting `type` all together):

{"name":""}

You'll receive an error from the Keystone server.

[Varun Mittal (viral.mutant)]

I tried that too

- Where everything is missing

curl -i -X POST http://10.0.2.15:35357/v2.0/OS-KSADM/services -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: Passw0rd" -d '{"OS-KSADM:service": {}}'
HTTP/1.1 200 OK
Date: Mon, 15 Sep 2014 19:02:45 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 95
Content-Type: application/json

{"OS-KSADM:service": {"enabled": true, "type": null, "id": "935947d882384d16a75fe52e9c6b0a64"}}

-- type is missing
mittal@mittal-virtualbox:~$ curl -i -X POST http://10.0.2.15:35357/v2.0/OS-KSADM/services -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: Passw0rd" -d '{"OS-KSADM:service": {"name":""}}'
HTTP/1.1 200 OK
Date: Mon, 15 Sep 2014 19:03:04 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 107
Content-Type: application/json

{"OS-KSADM:service": {"enabled": true, "type": null, "name": "", "id": "950b5fe5828443159e346788c622e5c4"}}

- name is missing
mittal@mittal-virtualbox:~$ curl -i -X POST http://10.0.2.15:35357/v2.0/OS-KSADM/services -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: Passw0rd" -d '{"OS-KSADM:service": {"type":""}}'
HTTP/1.1 200 OK
Date: Mon, 15 Sep 2014 19:03:13 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 93
Content-Type: application/json

{"OS-KSADM:service": {"enabled": true, "type": "", "id": "6587914826d34897b9d0789c301ee877"}}

[Varun Mittal (viral.mutant)]

Looking at the code in catalog/backends/sql.py , there is no validation in the service_create method to check if type is absent or empty string.

A simple ValidationError like following seems to fix it(in the initial/quick tests)

176 def create_service(self, service_id, service_ref):
177 session = self.get_session()
178 LOG.warning("service_ref is %s" % service_ref)
179 if not service_ref.has_key('type') or len(service_ref['type']) == 0:
180 raise exception.ValidationError(attribute='type', target='create request')
181 with session.begin():
182 service = Service.from_dict(service_ref)
183 LOG.warning("service is %s" % service)
184 session.add(service)
185 return service.to_dict()

Thoughts ?

[Varun Mittal (viral.mutant)]

I forgot to mention that I am referring to V2 here.

[Steve Martinelli (stevemar)]

Looks like we need some validation here

[Steve Martinelli (stevemar)]

It looks like there are 2 issues here:

  1) Lack of validation for v2 service create/update calls
  2) Lack of detecting duplicate services in the backend

For #1 - this be resolved by re-using the validation schema that v3 uses:
something like @validation.validated(schema.service_create, 'OS_KSADM_service') before the v2 service controller.

For #2 - not sure why the conflict this isn't being detected, and this would be a change in behaviour, not sure how we should proceed here.

[Steve Martinelli (stevemar)]

@Varun - can you try and see if you experience the same behaviour for v3.

As a team we do not want to continue to invest work for v2 Keystone, if this is only an issue for v2 then I will mark this as Won't Fix.

[Varun Mittal (viral.mutant)]

I tried this with V3

curl -i -X POST http://10.0.2.15:35357/v3/services -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: Passw0rd" -d '{"service": {"name":"junk"}}'
HTTP/1.1 400 Bad Request
Date: Mon, 22 Sep 2014 17:48:42 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 92
Connection: close
Content-Type: application/json

{"error": {"message": "'type' is a required property", "code": 400, "title": "Bad Request"}}

And it fails as expected

This too:
curl -i -X POST http://10.0.2.15:35357/v3/services -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "X-Auth-Token: Passw0rd" -d '{"service": {}}'
HTTP/1.1 400 Bad Request
Date: Mon, 22 Sep 2014 17:49:26 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 92
Connection: close
Content-Type: application/json

{"error": {"message": "'type' is a required property", "code": 400, "title": "Bad Request"}}

Though we can still create service with same names and type, but that is by design.

So we can mark this one as Won't Fix

[Morgan Fainberg (mdrnstm)]

As per comment #11 this is being marked as "wont fix" since it's V2 related and V3 works as expected.