I’ve been a happy Dreamhost customer for many years. So I was thrilled when I heard that they had upgrade Dreamcompute to Mitaka. So, like the good Keystoner that I am, I went to test it out. Of course, I tried to use the V3 API.  And it failed.
What? Dreamhost wouldn’t let me down, would they?
No. V3 works fine, it is discovery that is misconfigured.
If you do not tell the openstack client (and thus keystoneauth1) what plugin to use, it defaults to the non version specific Password plugin that does version discovery, What this means is it will go to the auth URL you give it, and try to figure out what the right version to use is. And, it so happens that there is a nasty bit of Keystone which is not well documented that makes the dreamhost /v3 page look like this:
$ curl $OS_AUTH_URL
{"version": {"status": "stable", "updated": "2013-03-06T00:00:00Z", "media-types":
[{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"},
{"base": "application/xml", "type": "application/vnd.openstack.identity-v3+xml"}], "id":
"v3.0", "links": [{"href": "https://keystone-admin.dream.io:35357/v3/", "rel": "self"}]}}
See that last link?
Now, like a good service provider, Dreamhost keeps its Keystone administration inside, behind their firewall.
nslookup keystone-admin.dream.io Server: 75.75.75.75 Address: 75.75.75.75#53 Non-authoritative answer: Name: keystone-admin.dream.io Address: 10.64.140.19 [ayoung@ayoung541 dreamhost]$ curl keystone-admin.dream.io
Crickets…hangs. Same with a request to 35357. And since the Password auth plugin is going to use the URL from the /v3 page, which is
https://keystone-admin.dream.io:35357/v3.
To get around this, Dreamhost will shortly change their Keystone config file:Â If they have the base line config shipped with Keystone, they have, in the section:
[DEFAULT] admin_endpoint = <None>
Which is what is used in discovery to build the URL above. yeah, It is dumb. Instead, they will set it to
https://keystone.dream.io/
And discovery will work.
But I am impatient, and I want to test it now. The work around is to bypass discovery and specify the V3 version of the Keystoneauth1 Password protocol. The version specific plugin uses the AUTH_URL as provided to figure out where to get tokens. With the line:
export OS_AUTH_TYPE=v3password
And now…
$ openstack server show ipa.younglogic.net +--------------------------------------+---------------------------------------------------------+ | Field | Value | +--------------------------------------+---------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | iad-1 | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2016-06-17T03:28:48.000000 | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | private-network=2607:f298:6050:499d:f816:3eff:fe6a:afdb, 10.10.10.75, 173.236.248.45 | | config_drive | | | created | 2016-06-17T03:27:09Z | | flavor | warpspeed (400) | | hostId | 4a7c64b912cfeda73c2c56ac52e8ffd124aac29ec54e1e4902d54bd4| | id | f0f46fd3-fa59-4a5b-835d-a638f6276566 | | image | CentOS-7 (c1e8c5b5-bea6-45e9-8202-b8e769b661a4) | | key_name | ayoung-pubkey | | name | ipa.younglogic.net | | os-extended-volumes:volumes_attached | [] | | progress | 0 | | project_id | 9c7e4956ea124220a87094a0a665ec82 | | properties | | | security_groups | [{u'name': u'ayoung-all-open'}] | | status | ACTIVE | | updated | 2016-06-17T03:28:24Z | | user_id | b6fd4d08f2c54d5da1bb0309f96245bc | +--------------------------------------+---------------------------------------------------------+ |
And how cool is that: they are using IPv6 for their private network.
If you want to generate your own V3 config file from the file they ship, use this.