The code has been moved into openstacksdk. Make os-client-config a
thin wrapper around that code.
The legacy client code needs to stay, as it was removed in openstacksdk.
We also have to plumb os_client_config.defaults and
os_client_config.cloud_region.CloudRegion in so that users get the
os-client-config versions from the openstacksdk methods that return the
relevant objects.
Support for per-service region_name has been dropped. This was never
used anywhere and was added for compatibility with openstacksdk Profile
objects. Since Profile objects are no more, we can remove it. It never
made any sense.
Change-Id: I7180e20aa675c0ccbe3718493a6eff2be7e1b8b6
Some clouds require that users add a floating IP to a server if the user
wants that server to be able to talk to things that are not on the
cloud. Some clouds do not require this and instead give servers a
directly attached IP. The only way a user can know is to boot a server,
then ask neutron for the port associated with that server, then find the
network the port came from and then try to infer whether or not that
network has the ability to route packets northbound. Of course, networks
don't actually communicate that quality directly, (router:external
doesn't mean a network routes externally, it means the network can have
a router attached to it to provide floating ips) so it's still hit and
miss.
Where we can, save the user the stress and strain of not knowing how
their cloud wants them to get an externally routable IP.
Change-Id: I1baf804ce28bc1997b2347c4648c5cc56c750ead
VEXXHOST cloud uses SSL for Keystone and all other services,
change the auth URL to the SSL endpoint.
Change-Id: If80c76603de44d005d6af1726f34d924384bf747
There is a discovery URL for vexxhost for keystone v3. Also, there is a
new vexxhost domain for it. Also, vexxhost has DNS running designate v1.
And make the region list a list of one region, because there is a second
region coming soon.
Change-Id: Ie72c19976646f41c713124659e69725df59e1580
In preparation for sharing the default and vendor data with other
projects, potentially even non-python ones, move the data into json
format, which is slighly less exciting to read, but has more widespread
standard library support. The user-facing config file will still be in
yaml format, because that's easier on the eyes and it's expected to be
read and edited by humans.
Continue to accept yaml everywhere, because an end user may have dropped
a yaml config file into a dir somewhere, and that's fine.
Change-Id: I269d31e61da433ac20abb39acdde0f9f9fe12837
Monty Taylor