can create the same type and name of a service with v3 API

[lumeihong]

i create a service as follows,it can be successful.
curl -H "X-Auth_Token:fc1629a543c64be18937ba8a1296468b" -H "Content-type: application/json" -d '{"service":{"description":"test_service","name":"name_service","type":"test_servce"}}' http://localhost:35357/v3/services |python -mjson.tool
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 325 100 240 100 85 1265 448 --:--:-- --:--:-- --:--:-- 1269
{
    "service": {
        "description": "test_service",
        "enabled": true,
        "id": "2d0da8b3d57b4d35a53d4b4a6659b8e4",
        "links": {
            "self": "http://localhost:35357/v3/services/2d0da8b3d57b4d35a53d4b4a6659b8e4"
        },
        "name": "name_service",
        "type": "test_servce"
    }

when i create a service with the same command again,it still can be successful. the service list is as follows,there are two records with the same name and type.

curl -H "X-Auth_Token:89abc0b308154bb59b5fcc8bd95669f5" http://localhost:35357/v3/services |python -mjson.tool
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 1920 100 1920 0 0 7874 0 --:--:-- --:--:-- --:--:-- 7901
{
    "links": {
        "next": null,
        "previous": null,
        "self": "http://localhost:35357/v3/services"
    },
    "services": [
        {
            "description": "OpenStack Networking",
            "enabled": true,
            "id": "18c27349d6bf4606a81239164a9be42b",
            "links": {
                "self": "http://localhost:35357/v3/services/18c27349d6bf4606a81239164a9be42b"
            },
            "name": "neutron",
            "type": "network"
        },
        {
            "description": "test_service",
            "enabled": true,
            "id": "2d0da8b3d57b4d35a53d4b4a6659b8e4",
            "links": {
                "self": "http://localhost:35357/v3/services/2d0da8b3d57b4d35a53d4b4a6659b8e4"
            },
            "name": "name_service",
            "type": "test_servce"
        },

        {
            "description": "test_service",
            "enabled": true,
            "id": "9af35c8f07c541d08b7bd4b65a0307da",
            "links": {
                "self": "http://localhost:35357/v3/services/9af35c8f07c541d08b7bd4b65a0307da"
            },
            "name": "name_service",
            "type": "test_servce"
        },

    ]
}

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

the service type should have a unique constraint

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

the name is not really required as it is user given name, but the service_type definitely must be unique otherwise it will cause problem in the catalog.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/175290

[Steve Martinelli (stevemar)]

@lin, i feel like certain deployers probably use the same type value multiple times. we should double check that we aren't breaking any one if we enforce it. would it be so wrong to have 2 object store services?

[Dave Chen (wei-d-chen)]

There is a similar bug here: https://bugs.launchpad.net/keystone/+bug/1403408, there is something uncertainty in the bug, this is why that issue is pending there. pls see my comment.

The issue can be found in other keystone entity as well, I am considering to register a BP to address all the similar problem in the Keystone.

[David Stanek (dstanek)]

IIRC Steve is correct. I remember talking about this in the past. If it is true and deployers do take advantage of this functionality then we should add a test for it to document that it is the expected behavior.

@Dave: besides the one you link to are there others that you know of?

[Dolph Mathews (dolph)]

I don't see any reason for this to be a "Medium" bug - there's absolutely no negative impact described here. In fact, the documented behavior is as-designed. To quote myself from the code review above:

  The most obvious conflicting use case I can think of is having two services of the same type in the same region with different guarantees around performance, availability, etc. Perhaps those two services are branded differently (different service names), and incur different billing behaviors.

Furthermore, if there actually is a user experience issue here, a deployer could solve it through endpoint filtering (exposing one service to one subset of users, and exposing the second service to another subset of users). Otherwise, any bug that could result from this is either because the user is ambiguously choosing endpoints and / or the client isn't providing sufficient feedback to cater to the scenario.

[Morgan Fainberg (mdrnstm)]

The client collapses the endpoints into a single list (that was a previous bug) and this could break a number of deployments of the service.type is made unique. There are a number of large deployers that have made use of this.

We can make service.name and service.type a unique combination to avoid duplicates if it is not already that way. However, this cannot be changed.

[Dave Chen (wei-d-chen)]

@David, see the entries below, maybe it is not necessary to make unique combination on (name, fitlers).

mysql> select * from endpoint_group;
+----------------------------------+---------------------+----------------------------+------------------------+
| id | name | description | filters |
+----------------------------------+---------------------+----------------------------+------------------------+
| 45b122d470d54cd5aa325bd028e51441 | endpoint_group_name | endpoint group description | {"interface": "admin"} |
| 5db2275539d94b258cd3c6976b2c80df | endpoint_group_name | endpoint group description | {"interface": "admin"} |
| af37fa8122404102a91fed908fe62994 | endpoint_group_name | endpoint group description | {"interface": "admin"} |
+----------------------------------+---------------------+----------------------------+------------------------+
3 rows in set (0.02 sec)

[OpenStack Infra (hudson-openstack)]

Change abandoned by huanghao (<email address hidden>) on branch: master
Review: https://review.openstack.org/175290
Reason: Abandon since it's wont be fixed