| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-06-13 | |||
| 14:11:32 | mnaser | i'm still getting a traceback in my code but who knows | |
| 14:11:40 | cdent | same or different? | |
| 14:11:46 | cdent | (traceback and code) | |
| 14:12:27 | mnaser | same code http://paste.openstack.org/show/723387/ giving same traceback | |
| 14:12:38 | cdent | drop the override? | |
| 14:12:51 | mnaser | oh right | |
| 14:14:31 | cdent | I'm concered confused by why the override didn't work, but I'm struggling to speculate because of lack of familiarity with the tools | |
| 14:15:48 | mnaser | i cant even get my `clouds.yaml` running properly | |
| 14:17:00 | mnaser | ok no my clouds.yaml is fine | |
| 14:17:30 | mnaser | http://paste.openstack.org/show/723390/ gives me http://paste.openstack.org/show/723391/ | |
| 14:17:43 | mnaser | (the nova print flavors parts works fine) | |
| 14:17:55 | openstackgerrit | Graham Hayes proposed openstack/os-api-ref master: General overhaul of testing setup https://review.openstack.org/575124 | |
| 14:23:26 | cdent | mnaser: i guess something is having trouble understanding how to define auth handling durig make_rest_client, but again, I've got no insight into that code. | |
| 14:24:00 | mnaser | cdent: yeah i tried digging into it but it is way beyond me :( it's not a fun user experience but then again not many people interact with the placement api directly i assume | |
| 14:24:44 | cdent | as far as I can tell the problems you're experience aren't because of placement itself, it is something about how the libraries are trying to contact it | |
| 14:24:51 | cdent | placement itself is way simple | |
| 14:25:09 | cdent | if curl to placement with a valid keystone token, it will just work | |
| 14:25:38 | cdent | but i'm not normal | |
| 14:28:49 | mnaser | cdent: oh yeah, i agree, but i'm saying that the tooling to get me something that interacts with it relatively cleanly doesn't exist fully yet | |
| 14:28:56 | mordred | cdent, mnaser: I'm confused both as to why override did not work and also why it's not working now- I still get the same error as before | |
| 14:29:10 | mnaser | don't want to start building out something using requests etc | |
| 14:29:27 | mordred | oh - I think I have an idea | |
| 14:31:01 | mordred | mnaser: can you try adding placement_api_version to your clouds.yaml? (we're still 2 patches away from having discovery work right without having a configured api version) | |
| 14:31:24 | mordred | mnaser: so placement_api_version: 1 | |
| 14:31:38 | mnaser | "IndexError: list index out of range" | |
| 14:31:46 | mordred | sigh | |
| 14:32:22 | mnaser | mordred: http://paste.openstack.org/show/723392/ this is where i am at right now | |
| 14:32:37 | mordred | yah- that looks right | |
| 14:36:16 | mnaser | feel free to throw things my way but i've hit a wall personally, i'd have to figure out the inner working of all of this to work any further | |
| 14:37:30 | mordred | yah - I'll figure it out | |
| 14:39:45 | openstackgerrit | Graham Hayes proposed openstack/os-api-ref master: General overhaul of testing setup https://review.openstack.org/575124 | |
| 14:41:39 | mordred | heh | |
| 14:41:41 | mordred | cdent: $ curl http://placement-ca-ymq-1.vexxhost.net/ | |
| 14:41:43 | mordred | {"versions": [{"status": "CURRENT", "min_version": "1.0", "max_version": "1.17", "id": "v1.0"}]} | |
| 14:42:00 | mordred | there's no links dict | |
| 14:42:17 | cdent | yeah, never has been. is that a problem too? | |
| 14:42:38 | mordred | it's what tells a discovery client where the given endpoint is | |
| 14:42:48 | cdent | you're already there | |
| 14:43:17 | mordred | but a discovery consumer doesn't know that | |
| 14:43:32 | cdent | one sec | |
| 14:43:39 | mordred | for all of the other services, the discovery document is an index to where the actual endpoints are | |
| 14:43:56 | mordred | $ curl http://compute-ca-ymq-1.vexxhost.net/ | |
| 14:43:57 | mordred | {"versions": [{"status": "SUPPORTED", "updated": "2011-01-21T11:33:21Z", "links": [{"href": "http://compute-ca-ymq-1.vexxhost.net/v2/", "rel": "self"}], "min_version": "", "version": "", "id": "v2.0"}, {"status": "CURRENT", "updated": "2013-07-23T11:33:21Z", "links": [{"href": "http://compute-ca-ymq-1.vexxhost.net/v2.1/", "rel": "self"}], "min_version": "2.1", "version": "2.60", "id": "v2.1"}]} | |
| 14:44:17 | cdent | because they are hilariously antiquated things that do weird things like put versions in urls on the same service endpoint for | |
| 14:44:26 | mordred | well - sure | |
| 14:44:39 | cdent | for modern things that don't do such blasphemy, if no link rel self then endpoint is what you already requested | |
| 14:45:05 | cdent | that was supposed to come out as a question, not a dammit! | |
| 14:45:41 | cdent | mordred: i can stick it in too, to that same patch, but it seems...weird | |
| 14:45:55 | mordred | that would be a potential behavior change in keystoneauth ... https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/discover.py#L543-L547 | |
| 14:46:31 | mordred | kmalloc: ^^ if we stopped skipping entries with no self link and used that to infer that the existing endpoint was the self-link - would you consider that a breaking change to keystoneauth? | |
| 14:46:49 | cdent | i'm happy to fix placement to make life easier | |
| 14:47:05 | cdent | but I think we want to make room for a future where endpoints are endpoints and that's it | |
| 14:47:18 | kmalloc | mordred: hm | |
| 14:47:21 | kmalloc | reading up | |
| 14:48:26 | kmalloc | mordred: it would be a breaking change, behavior changes are breaking =/ | |
| 14:48:50 | mordred | nod. we can queue that up for keystoneauth2 | |
| 14:49:07 | cdent | still confused on how it is currently working for nova? | |
| 14:49:20 | mordred | cdent: that is honestly a fascinating question | |
| 14:49:22 | kmalloc | yeah. i am inclined to say we should ksa2 at this point and drop some behavior | |
| 14:49:24 | cdent | s/still/I am still/ | |
| 14:49:43 | kmalloc | well... if it has links but no self | |
| 14:49:46 | kmalloc | it doesn't skip | |
| 14:49:53 | cdent | no links at all | |
| 14:49:57 | kmalloc | hm. | |
| 14:50:08 | cdent | so maybe the problem is not at the ksa level? | |
| 14:50:20 | kmalloc | maybe. | |
| 14:50:23 | cdent | in which case I'd argue against changing placement /, perhaps? | |
| 14:50:41 | mordred | cdent: yah - it might be that sdk is triggering version discovery where nova + plain ksa is not | |
| 14:50:51 | kmalloc | likely | |
| 14:51:07 | kmalloc | sdk does stuff in some more indirect ways. | |
| 14:51:15 | mordred | cdent: I would prefer to not special-case placement in sdk with a "please don't try version discovery on placement" - also, it'll break discovering available microversions | |
| 14:51:45 | kmalloc | mordred: ftr, i would love to stop skipping no-link items | |
| 14:51:47 | cdent | i'm not suggesting to avoid version discovery | |
| 14:51:56 | kmalloc | i just see some "this might actually break someone" | |
| 14:52:00 | kmalloc | potential | |
| 14:52:03 | cdent | well if you both feel that way I'll add a link | |
| 14:52:14 | cdent | I don't feel strongly about it | |
| 14:52:14 | mordred | cdent: yah - but nova's use of ksa is really only likely able to work by using ksa in such a way that version discovery is being avoided | |
| 14:52:24 | kmalloc | cdent: i don't want you to add a link, i don't think we can change ksa's behavior | |
| 14:52:30 | mordred | yah - I think the link is silly | |
| 14:52:33 | kmalloc | cdent: so, adding a link might be the correct way | |
| 14:52:45 | kmalloc | just not the desirable one | |
| 14:53:08 | cdent | what I do feel strongly about is having version numbers in urls and double endpoints | |
| 14:53:13 | kmalloc | mordred: i dislike the volume of inherited ick we carried over from ksc.session | |
| 14:53:18 | mordred | kmalloc: yah | |
| 14:53:23 | mordred | cdent: totally. | |
| 14:53:23 | cdent | but we are in the reality we are in so... | |
| 14:53:28 | kmalloc | cdent: please please please don't do version numbers in urls if you can avoid. | |
| 14:53:38 | kmalloc | cdent: so.. i am with you there | |
| 14:53:58 | kmalloc | mordred: how bad would it be to cut a ksa2 and drop compat behaviors [for sdk] | |
| 14:54:00 | cdent | kmalloc: yeah, don't plan to: placement was designed from the outset to never do that | |
| 14:54:10 | kmalloc | and start iterating on that instead of ksa1 continues? | |
| 14:54:21 | kmalloc | cdent: ++ and i appreciate that so very much! | |
| 14:54:23 | mordred | kmalloc: I don't think it would be _bad_ - but I think it would take us a few months | |
| 14:54:49 | kmalloc | mordred: well we'd need to ksa2 work anyway. i'm inclined to talk to lbragstad about it | |
| 14:54:56 | mordred | kk | |
| 14:55:04 | kmalloc | ksa1 is pretty stable, and we could make ksa2 just without all the icky compat stuff. | |
| 14:55:23 | cdent | can you guys speculate what ksa or the sdk would do if I set the href for the self link to '' | |
| 14:55:41 | mordred | I'll show you the code | |
| 14:56:04 | cdent | I want to do that because no where in placement does placemet know its own scheme, hostname, port, base url. And it is very important that it stay that way | |