On 03/16/2015 11:22 AM, Russell Bryant wrote: > On 03/16/2015 11:08 AM, John Garbutt wrote: >> While its not under Nova's control, I think we need to consider the >> keystone catalog here. >> >> It feels nice to have an explicit entry for v2.1, that people start >> using once the client is updated to support microversions. DefCore >> would eventually check for the presence of that entry. >> >> Eventually, the v2 entry would be served by the v2.1 code, once we are >> happy its not going to break too many folks, at least including all >> the major SDKs. I hope thats during Liberty. > > I'd really rather get away from any explicit entries in the keystone > service catalog for API versions. It seems kind of broken to me. I > think the service catalog should only have enough to point you to the > APIs location. Discovering and choosing versions should be done by the > client and not embedded in the service catalog.
Long term I think that's sensible. The problem is today Nova doesn't manage it's service catalog entry itself. So it's a manual process that people are have to do themselves. And today we tell them to make version specific endpoints in the official install guide - http://docs.openstack.org/juno/install-guide/install/apt/content/ch_nova.html#nova-controller-install ("Create the Compute service API endpoints"). Devstack also does things similarly, which while not official recommendations in any way, is a thing people tend to replicate in other environments. We need longer term normalization of the service catalog rules for interop for sure. But I think that's currently out of our hands. Which brings back the question of defaults for Kilo. The whole v2.1 effort was for seamless additions. I don't know that we're going to know if we did that right unless we start defaulting that way for new installs. Again, paste.ini is config in etc, so deployers can change it any way they want. We don't get hard enforcement here. Just suggested defaults. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
