| *** mhen_ is now known as mhen | 01:18 | |
| dansmith | can someone help me with a stupid keystoneauth/client/whatever question? | 16:31 |
|---|---|---|
| dansmith | when I access something like devstack using tls-proxy, the URLs are (as expected) prefixed with /service/blah | 16:31 |
| dansmith | rel links within json documents will include that, so /placement/foo/bar | 16:32 |
| dansmith | if I use one of those to make another call, keystone client will re-prefix it and I'll get /placement/placement/foo/bar | 16:32 |
| dansmith | I can strip off the first, of course, but then that same code doesn't work when used with a deployment that does not have a /placement prefix | 16:33 |
| gtema | are there anywhere relative links (in catalog, in version discovery doc, etc)? | 16:33 |
| dansmith | I'm not sure how to answer that.. this is what I'm looking at: https://docs.openstack.org/api-ref/placement/#id8 | 16:34 |
| dansmith | those "links" have /placement already prefixed, if I just grab one and call that with the client, it will try to hit /placement/placement/blah | 16:35 |
| gtema | you need to check how the service catalog looks like (openstack catalog show placement), and in addition to that send authenticated request to http(s)://api/placement/ | 16:35 |
| gtema | and check how the version document look like | 16:36 |
| dansmith | okay so I'm supposed to determine it myself, and strip the /placement off the link myself if it looks like the catalog already has that in it? | 16:37 |
| dansmith | I was expecting this to be automatic I guess, like keystoneauth seeing that it was already prefixed or something | 16:37 |
| gtema | no, I mean that if some of the docs is using relative links things may recursively duplicate | 16:38 |
| gtema | imagine service catalog points to http://api/placement and version doc at that address says: placement/ - then it would be doubled | 16:38 |
| gtema | that would be deployment bug | 16:39 |
| dansmith | okay I'm not quite sure I understand.. let me grab some of those things and show you what I'm looking at | 16:39 |
| dansmith | this is standard devstack | 16:39 |
| gtema | I do not have devstack at hand right now, and I do not play with placement | 16:40 |
| gtema | I have found some devstack. Placement version discovery doc looks like that: {"versions":[{"id":"v1.0","links":[{"href":"","rel":"self"}],"max_version":"1.39","min_version":"1.0","status":"CURRENT"}]} | 16:44 |
| dansmith | https://paste.opendev.org/show/byWstXnuUAYWvSm1DOug/ | 16:44 |
| dansmith | the endpoint has /placement in it (of course) | 16:44 |
| dansmith | and the links that are returned from placement in a doc include /placement | 16:44 |
| dansmith | so if I do session.get(links[0]['href']) it will try to get /placement/placement/resource_providers/... | 16:45 |
| dansmith | my version discovery doc looks like yours, yep.. with href:"" | 16:47 |
| gtema | for me this is a sort of bug: either the service should return absolute urls or relative links are relative to the current url. At least this is the base principle of openstack catalog consumption | 16:47 |
| gtema | oh well, not to the current url (what could be as well), but to the base of where the placement is deployed | 16:48 |
| dansmith | meaning links should have /resource_provider in them? or the version doc should have /placement in the self href? | 16:49 |
| gtema | cause the catalog endpoint discovery identified placement base as http://placement/api and relative link is appended to that - OpenStack is full of dumb concats resulting in double slashes and similar insanity | 16:49 |
| dansmith | I guess I'm not sure how nova (et al) works, since it seems to work for either case | 16:50 |
| gtema | yes, if links would be /resource_provider (with or without leading slash is hard to say) it should work | 16:50 |
| gtema | not a single core service that is intended to be used by the user is returning relative links to the user under the normal recommended conditions | 16:51 |
| gtema | at least not that I have seen one | 16:51 |
| dansmith | yeah, I guess I will have to dig into what nova is doing to make this work for the /placement and / cases both, because me trying to write a standalone client, I'm not sure | 16:52 |
| gtema | and placement was stated not designed to be used by the user | 16:52 |
| gtema | I think placement by default just "hopes" it is deployed under the root and does not worry about anything else | 16:52 |
| dansmith | I don't think so, because if so, it wouldn't be returning /placement prefixed to the urls | 16:55 |
| dansmith | and if you deploy devstack without tls-proxy, it will be on its own port and at the root, and then it does not prefix with /placement | 16:55 |
| gtema | ok, that means deployment respects how it is published, but relative urls are always bad | 16:57 |
| gtema | a question is where the url construction happens. Do you use keystoneauth or sdk? | 16:58 |
| dansmith | yeah, understand | 16:58 |
| dansmith | gtema: tbh I don't really know where the delineation is, but I'm doing a session.get(url) so I assume that's all keystoneauth | 16:58 |
| dansmith | I'm guessing maybe none of the nova code uses the links structure and so it doesn't know about this stuff | 16:59 |
| gtema | most likely | 16:59 |
| dansmith | and that's why it works in either place - because session prefixes or doesn't | 16:59 |
| gtema | and yes, session.get would be in the keystoneauth which either uses the absolute url or appends the relative url to the catalog endpoint (which is already /placement) | 16:59 |
| dansmith | is there an easy way I can see what the current session points to? so I can compare the suffix of that to the prefix of the link url? | 17:00 |
| gtema | https://opendev.org/openstack/keystoneauth/src/branch/master/keystoneauth1/session.py#L921 should be what happens | 17:02 |
| dansmith | okay maybe I can at least probe some of that to see if I should strip or not | 17:04 |
| gtema | the easiest would be really just to fix the deployment so that relative links from placement are relative to where the catalog points to | 17:06 |
| gtema | basically the placement link should be always the same (if it is relative link) | 17:06 |
| gtema | and the catalog should point to the correct entry point | 17:07 |
| gtema | introducing a-yet-another special case is not going to do any good | 17:07 |
| dansmith | the catalog is correct | 17:22 |
| dansmith | sounds to me like *placement* should be fixed to return links without a prefix | 17:22 |
| dansmith | and I agree, I'm just trying to make this work against deployments I don't control that are deployed with code that is already released | 17:23 |
| gtema | dansmith: I strongly believe devstack deployment sets some special confg option as api prefix or wsgi SCRIPT_NAME so that all links contain that as a prefix (https://opendev.org/openstack/placement/src/branch/master/placement/util.py#L187) | 17:30 |
| dansmith | okay I don't see it | 17:33 |
| dansmith | might be a uwsgi default | 17:33 |
| gtema | it maybe set somewhere in the wsgi config which may be somewhere else | 17:34 |
| dansmith | I looked in the systemd file and the wsgi file and I don't see it | 17:46 |
| dansmith | and I don't see SCRIPT_NAME anywhere in devstack/* | 17:46 |
| dansmith | but I agree, that's probably not the right thing to do in placement regardless | 17:46 |
| dansmith | gtema: unrelated, but.. how is valid_interfaces supposed to be honored by keystoneauth? I have valid_interfaces= set in the client config, but I seem to have to pass interface in the endpoint_filter to a session.request | 18:20 |
| dansmith | I assumed load_session_from_conf_options() to do the right thing for me, but it doesn't seem to | 18:20 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!