<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@gmail.com" target="_blank">jamielennox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 18 February 2016 at 10:50, Matt Fischer <span dir="ltr"><<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. </div></blockquote><div><br></div></span><div>Excellent! I'm really glad someone is looking into this beyond the simple cases.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Here's what I've found:</div><div><br></div><div>Using versionless endpoints:</div><div> - horizon project selector doesn't work (v3 api configured in horizon local_settings) [1]</div><div> - keystone client doesn't work (expected v3 I think)</div><div> - nova/neutron etc seem ok with a few exceptions [2]</div><div><br></div><div>Adding /v3 to my endpoints:</div><div> - openstackclient seems to double up the /v3 reference which fails [3], this breaks puppet-openstack, in addition to general CLI usage.</div><div><br></div><div>Adding /v2.0 to my endpoints:</div><div> - things seem to work the best this way</div><div> - this matches the install docs too</div><div> - its not very "v3-onic"</div><div><br></div><div><br></div><div>My goal is to be as v3 as possible, but everything needs to work 100%. Given that...</div><div><br></div><div>What's the correct and supported way to setup endpoints such that Keystone v3 works?</div></div></blockquote><div><br></div></span><div>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. <br><br></div><div>It does however explain why you see problems with /v3 where /v2.0 seems to work even for the v3 API. <br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Are services expected to handle versionless keystone endpoints properly?</div><div></div></div></blockquote><div><br></div></span><div>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.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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?</div></div></blockquote><div><br></div></span><div>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.  <br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Do I need/Should I have both v2.0 and v3 endpoints in my catalog?</div><div><br></div></div></blockquote></span><div>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.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>[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.</div><div><br></div><div>[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: <a href="https://etherpad.openstack.org/p/v3-only-devstack" target="_blank">https://etherpad.openstack.org/p/v3-only-devstack</a></div></div></blockquote><div><br></div></span><div>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. <br><br></div><div>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. <br><br></div><div>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. <br><br><br></div><div>Jamie <br></div></div></div></div></blockquote><div><br></div><div>Jamie,</div><div><br></div><div>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!</div><div><br></div><div>I will bring my test env back up later this week and work on bugs for both issues that I called out.</div></div></div></div>