**Ideally** you would provide unversioned endpoints for all services, e.g.:
http://keystone:35357/ instead of http://keystone:35357/v2.0/ ... and the client would work out what versions are supported and select a preferred version automatically. However, we're not quite there yet. I can't speak for nova and glance at the moment, but there will probably continue to have "recommended" endpoints for use in the catalog. For Havana, I would recommend /v2.0/ for keystone at this point (at least for the catalog), unless you know the client you're configuring supports properly supports an unversioned endpoint (auth_token) or a v3 endpoint (python-keystoneclient's python API, openstackclient, and auth_token). -Dolph On Thu, Mar 14, 2013 at 5:41 PM, Logan McNaughton <lo...@bacoosta.com>wrote: > I have a question on service endpoints. > I've read that Horizon depends quite heavily on them, and a > misconfiguration there can really mess things up. My question is, does the > endpoint need to be compatible with Horizon? > > For instance, as of Grizzly, Keystone will support /v2.0 and /v3 > Nova will support /v1.1 and /v2 > Glance will support /v1 and /v2 > Quantum will support a /v2 > > Can I safely use the latest endpoints (For instance, Keystone /v3), or > does Horizon only support certain endpoint versions? Can I have multiple > endpoints and create a /v2.0 and /v3? > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
