On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox <jamielen...@gmail.com> wrote:
> > > On 18 February 2016 at 10:50, Matt Fischer <m...@mattfischer.com> wrote: > >> I've been having some issues with keystone v3 and versionless endpoints >> and I'd like to know what's expected to work exactly in Liberty and beyond. >> I thought with v3 we used versionless endpoints but it seems to cause some >> breakages and some disagreement as to what should work. >> > > Excellent! I'm really glad someone is looking into this beyond the simple > cases. > > >> Here's what I've found: >> >> Using versionless endpoints: >> - horizon project selector doesn't work (v3 api configured in horizon >> local_settings) [1] >> - keystone client doesn't work (expected v3 I think) >> - nova/neutron etc seem ok with a few exceptions [2] >> >> Adding /v3 to my endpoints: >> - openstackclient seems to double up the /v3 reference which fails [3], >> this breaks puppet-openstack, in addition to general CLI usage. >> >> Adding /v2.0 to my endpoints: >> - things seem to work the best this way >> - this matches the install docs too >> - its not very "v3-onic" >> >> >> My goal is to be as v3 as possible, but everything needs to work 100%. >> Given that... >> >> What's the correct and supported way to setup endpoints such that >> Keystone v3 works? >> > > So the problem with switching to v3 is that a lot of services and clients > were designed to assume you would have a /v2.0 on your URL. To work with v3 > they therefore inspect the url and essentially s/v2.0/v3 before making > calls. Any of the services using the keystoneclient/keystoneauth session > stuff correctly shouldn't have this problem - but that is certainly not > everyone. > > It does however explain why you see problems with /v3 where /v2.0 seems to > work even for the v3 API. > > >> Are services expected to handle versionless keystone endpoints properly? >> > > Services should never need to manipulate the catalog. This is what's > causing the problem. If they leave it up to the client to do this then it > will handle the unversioned endpoint. > > >> >> > Can I ignore that keystoneclient doesn't work with versionless? Does this >> imply that services that use the python library (like Horizon) will also be >> broken? >> > > This I'm surprised by. Do you mean the keystone CLI utility that ships > with keystoneclient? If so the decision was made it should never support v3 > and to use openstackclient instead. I haven't actually looked at this in a > long time but we should probably fix it even though it's been deprecated > for a long time now. > > >> Do I need/Should I have both v2.0 and v3 endpoints in my catalog? >> >> No. And particularly with the new catalog formats that went through the > cross project working group recently we made the decision that these > endpoints should not contain a version number at all. This is not ready yet > but we are working towards that goal. > > >> [1] its making curl calls without a version on the endpoint, causing it >> to fail. I will file a bug pending the outcome of this discussion. >> >> [2] specifically neutron_admin_auth_url in nova.conf doesn't seem to work >> without a Keystone API version on it. For cinder keymgr_encryption_auth_url >> also seems to need it. I assume I'll eventually also hit some of these: >> https://etherpad.openstack.org/p/v3-only-devstack >> > > Can you file bugs for both of these? I've worked on both these sections > before so should be able to have a look into it. > > I was going to finish by saying that we have unversioned endpoints in > devstack - but looking again now and we don't :( There have been various > reverted patches in the v3 transition and this must have been one of them. > > For now i would suggest keeping the endpoints with the /v2.0 prefix as > even things using v3 API know how to work around this. The goal is to go > versionless everywhere (including other services, long goal but the others > will be easier than keystone) and anything you find that isn't working > isn't using the clients correctly so file a bug and add me to it. > > > Jamie > Jamie, Apologies for the delay in response and thanks for the information. I had come to the same conclusion as you after sending this, leaving /v2.0 on the URLs in the catalog but specifying v3 seems to work the best for now in Liberty. I look forward to the day when v3+versionless is the default! I will bring my test env back up later this week and work on bugs for both issues that I called out.
__________________________________________________________________________ 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