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

Bug #1439928 reported by lumeihong on 2015-04-03
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Unassigned

Bug Description

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"
        },

    ]
}

Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

the service type should have a unique constraint

Changed in keystone:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

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.

Changed in keystone:
status: Confirmed → Triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

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

Changed in keystone:
assignee: nobody → huanghao (huang1hao)
status: Triaged → In Progress
Revision history for this message
Steve Martinelli (stevemar) wrote :

@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?

Revision history for this message
Dave Chen (wei-d-chen) wrote :

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.

Revision history for this message
David Stanek (dstanek) wrote :

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?

Revision history for this message
Dolph Mathews (dolph) wrote :

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.

Changed in keystone:
status: In Progress → Won't Fix
Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

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.

Revision history for this message
Dave Chen (wei-d-chen) wrote :

@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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on keystone (master)

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

huanghao (huang1hao) on 2015-04-22
Changed in keystone:
assignee: huanghao (huang1hao) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers