APIv3 compatibility broken in Mitaka and Liberty

[Antonio Ojea]

Current API documentation [1] uses the fields "domain": { "id": "default" }, to select a domain.

This call works in Liberty as you can see in the following snippet:

curl -i -H "Content-Type: application/json" -d '
{ "auth": {
    "identity": {
      "methods": ["password"],
      "password": {
        "user": {
          "name": "admin",
          "domain": { "id": "default" },
          "password": "admin"
        }
      }
    },
    "scope": {
      "project": {
        "name": "admin",
        "domain": { "id": "default" }
      }
    }
  }
}' http://172.17.0.3:5000/v3/auth/tokens ; echo
HTTP/1.1 201 Created
X-Subject-Token: 8e861d59fb1847a388b27ab7150f2d15
Vary: X-Auth-Token
X-Distribution: Ubuntu
Content-Type: application/json
Content-Length: 2794
X-Openstack-Request-Id: req-2fcb81ac-4adf-4d0d-85f9-41d355c0606d
Date: Tue, 28 Jun 2016 08:59:42 GMT

{"token": {"methods": ["password"], "roles": [{"id": "b1abb292e4af4ead9a1b62b4a6e39ba4", "name": "__member__"}, {"id": "f071d23c5131434e8823101f3b8e33db", "name": "admin"}], "expires_at": "2016-06-28T09:59:42.646127Z", "project": {"domain": {"id": "default", "name": "Default"}, "id": "890fc0394fe34024b62aab12fb335960", "name": "admin"}, "catalog": [{"..."}], "extras": {}, "user": {"domain": {"id": "default", "name": "Default"}, "id": "d1b7876ff28e4db29296797296daecfe", "name": "admin"}, "audit_ids": ["7p_bhw8tTvqAOjKRpkHE2Q"], "issued_at": "2016-06-28T08:59:42.646167Z"}}

but it's turned out that in mitaka it fails if you use the id field with the name of the domain:

curl -i -H "Content-Type: application/json" -d '
{ "auth": {
    "identity": {
      "methods": ["password"],
      "password": {
        "user": {
          "name": "admin",
          "domain": { "id": "default" },
          "password": "openstack"
        }
      }
    },
    "scope": {
      "project": {
        "name": "admin",
        "domain": { "id": "default" }
      }
    }
  }
}' http://localhost:5000/v3/auth/tokens ; echo
HTTP/1.1 401 Unauthorized
Date: Tue, 28 Jun 2016 09:01:04 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
X-Distribution: Ubuntu
x-openstack-request-id: req-4898044b-25d4-4b9d-96c4-d823c0107cb0
WWW-Authenticate: Keystone uri="http://localhost:5000"
Content-Length: 114
Content-Type: application/json

{"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}}

in order to work you need to use name instead id:

curl -i -H "Content-Type: application/json" -d '
{ "auth": {
    "identity": {
      "methods": ["password"],
      "password": {
        "user": {
          "name": "admin",
          "domain": { "name": "default" },
          "password": "openstack"
        }
      }
    },
    "scope": {
      "project": {
        "name": "admin",
        "domain": { "name": "default" }
      }
    }
  }
}' http://localhost:5000/v3/auth/tokens ; echo
TTP/1.1 201 Created
Date: Tue, 28 Jun 2016 09:01:53 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Subject-Token: 0c293d9ceeba4a9f8c1a9edba99a1b11
Vary: X-Auth-Token
X-Distribution: Ubuntu
x-openstack-request-id: req-1a414584-472f-4b87-9981-a838e3df6f4a
Content-Length: 4155
Content-Type: application/json

{"token": {"methods": ["password"], "roles": [{"id": "444fc66b35834eafb3936dca445b56de", "name": "admin"}], "expires_at": "2016-06-28T10:01:53.680623Z", "project": {"domain": {"id": "0a686f9a064c46eda176a8670d2af12e", "name": "default"}, "id": "7c34e27bfb53415daef0b1696886fec5", "name": "admin"}, "catalog": [{"...}], "user": {"domain": {"id": "0a686f9a064c46eda176a8670d2af12e", "name": "default"}, "id": "bcc79501b12948d1b48540bea231b89c", "name": "admin"}, "audit_ids": ["U-uBxUKqStWW557xSCmgKA"], "issued_at": "2016-06-28T09:01:53.680711Z"}}

breaking all the compatibility

[1] http://docs.openstack.org/developer/keystone/api_curl_examples.html

[Steve Martinelli (stevemar)]

What are the domain's actual ID and name? are you using a SQL backend that is case insensitive?

What happens with a non-default domain? Can you auth by ID with a non-default domain?

[Steve Martinelli (stevemar)]

FWIW, using the ID worked for me on the newton-1 driver (which isn't all that different from mitaka)

(war) $ curl -i -H "Content-Type: application/json" -d '
> { "auth": {
> "identity": {
> "methods": ["password"],
> "password": {
> "user": {
> "name": "admin",
> "domain": { "id": "default" },
> "password": "openstack"
> }
> }
> },
> "scope": {
> "project": {
> "name": "admin",
> "domain": { "id": "default" }
> }
> }
> }
> }' http://localhost:5000/v3/auth/tokens ; echo
HTTP/1.1 201 Created
Date: Tue, 28 Jun 2016 13:48:41 GMT
Server: Apache/2.4.18 (Ubuntu)
X-Subject-Token: 0a15849bbd54491e8e469ebdd3080543
Vary: X-Auth-Token
x-openstack-request-id: req-835d0361-d8c9-432a-bc0c-2b7bfa651d05
Content-Length: 4910
Content-Type: application/json

{"token": {"is_domain": false, "methods": ["password"], "roles": [{"id": "0b2b4b7a08314943a3c51c338986f4c1", "name": "admin"}], "is_admin_project": true, "project": {"domain": {"id": "default", "name": "Default"}, "id": "1037fcd24a704897966647fb20b12836", "name": "admin"}, "catalog": [{..."}], "type": "identity", "id": "f459eb6fd2ba46e69369ba77d41ad123", "name": "keystone"}], "expires_at": "2016-06-28T14:48:41.309420Z", "user": {"domain": {"id": "default", "name": "Default"}, "id": "507207e7aca946f5870689588f9b72a4", "name": "admin"}, "audit_ids": ["0AvSVbLJQ_m7fSRt3F0otg"], "issued_at": "2016-06-28T13:48:41.309464Z"}}

[Steve Martinelli (stevemar)]

i cannot reproduce the failure, all three variants that were reported in the bug work for me.

[Guang Yee (guang-yee)]

Looks like your default domain has changed in Mitaka?

"project": {"domain": {"id": "0a686f9a064c46eda176a8670d2af12e", "name": "default"}, "id": "7c34e27bfb53415daef0b1696886fec5", "name": "admin"},

"user": {"domain": {"id": "0a686f9a064c46eda176a8670d2af12e", "name": "default"}, "id": "bcc79501b12948d1b48540bea231b89c", "name": "admin"},

Are the backend consistent between the two releases? And how was data migration being done?

[Antonio Ojea (aojea)]

Thanks for your help, I have tested with centos with rdo repos pacakges and with ubuntu 14.04 and cloudring packages, and only work if I send the uuid.

The configuration is done following the openstack guides.

The sql backend is mariadb.

The details from the Ubuntu 14.04 environment are

ii keystone 2:9.0.0-0ubuntu1~cloud0 all OpenStack identity service - Daemons

root@controller:~# openstack domain list
+----------------------------------+---------+---------+--------------------------+
| ID | Name | Enabled | Description |
+----------------------------------+---------+---------+--------------------------+
| 021f4bc3d1a14ee897908db5b7a4903b | heat | True | Stack projects and users |
| 0a686f9a064c46eda176a8670d2af12e | default | True | Default Domain |
+----------------------------------+---------+---------+--------------------------+

if I use the UUID it works.

How can I check where is the mismatch?

[Antonio Ojea (aojea)]

Hi,

you can reproduce it with the following snippet with vagrant

Vagrantfile
-------------
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.provider "virtualbox" do |vb|
     vb.memory = "1024"
  end

  config.vm.provision "shell", path: "https://gist.githubusercontent.com/itsuugo/ee562d243c952b2260eff5757d745065/raw/6f268caa38ecd16f5bde153b8bcb0653ab262ff3/mitaka-keystone-ub14.sh"
end
---------------

[Antonio Ojea (aojea)]

#4 I tested in different environments deployed from scratch, that's the reason because the data is different

[Guang Yee (guang-yee)]

https://gist.githubusercontent.com/itsuugo/ee562d243c952b2260eff5757d745065/raw/6f268caa38ecd16f5bde153b8bcb0653ab262ff3/mitaka-keystone-ub14.sh seem incorrect. The default domain is not supposed to be created directly.

openstack domain create --description "Default Domain" default

It must be created with "keystone-manage bootstrap". See

https://github.com/openstack/keystone/blob/master/doc/source/configuringservices.rst#setting-up-credentials-with-keystone-manage-bootstrap

[Antonio Ojea (aojea)]

Then it's a documentation bug http://docs.openstack.org/mitaka/install-guide-ubuntu/keystone-users.html , no?

[Antonio Ojea (aojea)]

Wow this looks worse, the bootstrap works because ... it creates the default domain with the ID = default

oot@vagrant-ubuntu-trusty-64:~# openstack domain list --os-username admin --os-project-name admin --os-user-domain-id default --os-project-domain-id default --os-identity-api-version 3 --os-auth-url http://localhost:5000 --os-password s3cr3t
+----------------------------------+---------+---------+--------------------+
| ID | Name | Enabled | Description |
+----------------------------------+---------+---------+--------------------+
| aed65665d4ae47b2883a305ba13f5ebf | default | True | Default Domain |
| default | Default | True | The default domain |
+----------------------------------+---------+---------+--------------------+

[Guang Yee (guang-yee)]

I agree this is a doc bug.

[Antonio Ojea (aojea)]

Please check #10, the bootstrap works because the id field is the string "default", it has to be an uuid, don't make sense to have an string as ID. IMHO this is a bug in the bootstrap script.

Regarding the #9, it can be a bug, but in Liberty the docs says to configure in that way too and and you have to consider that an operator can create the domain without using the bootstrap script.

I agree that it has more sense the Mitaka implementation that use "id" to select the ID field of the domain in the query and "name" to select the NAME, but in liberty it was working and documented as I explained in #1, thus it should continue to work in that way to be compatible with other integrations (i.e. our client fails to authenticate against keystone because of this) and to permit the upgrade of OS version

[Steve Martinelli (stevemar)]

Looks like this is related to the way the shell script sets things up. And somewhat related to the difference between Liberty and Mitaka.

In Liberty we created the default domain automatically when the user ran the db_sync command. We removed this in favor of the deployer creating the domain themselves, like you do in your shell script, with:

  openstack domain create --description "Default Domain" default

The only difference this has is that the ID will be a UUID instead of "default". Only *new* deployments are affected. We don't change the ID of existing resources, if you upgraded from Liberty to Mitaka, it would be the same.

We removed creating the domain automatically in favor or running `keystone-manage bootstrap`, take a look at the docs: http://docs.openstack.org/developer/keystone/configuringservices.html#setting-up-credentials-with-keystone-manage-bootstrap it'll save you a lot of lines of code in your shell script.

[Antonio Ojea (aojea)]

I see my fault now, I was supposing that "default" in liberty was the Name field and it's the ID, and in Mitaka following the docs the "default" domain is the name but the ID is an uuid randomly generated.

Apologize for any inconvenience and appreciate your help @stevemar and @guang-yee.

[Steve Martinelli (stevemar)]

@itsuugo, no problem. Thanks for your patience and quick feedback

[Guang Yee (guang-yee)]

I still think there's a doc bug, that there's a apparent dichotomy of default domain. One bootstrapped via openstack cli and the other via keystone-manage cli. This inconsistency will create typical confusions like this one. We need to clearly stating what the default domain is for. What are the implications if we bootstrap it via public API (curl, openstack CLI, etc), versus bootstrap it via keystone-manage.

The other bugs is case sensitive versus case insensitive project and domain names. UX will suffer because of that. Though names are mutable, but they still need to be unique. I don't think we should punt this to the backend. We need to decide 1) whether names are case-sensitive or case-insensitive, and 2) enforce it in the code.