| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-06-13 | |||
| 13:59:33 | mordred | mnaser: I'm unfortunately in a morning of meetings - but I'm very interested in helping to solve this for real -so if I go dark for chunks of time I haven't forgotten about you | |
| 13:59:44 | mnaser | i tried openstacksdk and i was running into the same issues too, alongside is_public not being something changable (that has since been fixed but not released) | |
| 13:59:58 | mnaser | mordred: oh don't worry about it, as async as you want, im not in a total rush about this | |
| 14:02:33 | mordred | mnaser: fwiw, I can reproduce it locally: | |
| 14:02:35 | mordred | >>> import openstack | |
| 14:02:37 | mordred | >>> c=openstack.connect(cloud='vexxhost') | |
| 14:02:39 | mordred | >>> c.placement.get('/allocation_candidates') | |
| 14:02:55 | mordred | (give me same traceback) | |
| 14:03:41 | mnaser | mordred: at least it's not me doing something wrong, yay. if there's anything on our side to do, i can look into it but this is a queens deployment | |
| 14:04:10 | mordred | mnaser: how hard would it be for you to cherry-pick https://review.openstack.org/575117 onto your nova? | |
| 14:05:07 | mnaser | mordred: not very, but i'd be much happier doing it if that type of thing gets backported | |
| 14:05:33 | mnaser | like: if you want a cherry pick to see how it looks like with no guarantee that it will stay there (because we will redeploy from upstream stable and the cherry pick will disappear) | |
| 14:06:05 | mordred | cdent: what do you think the chances are we convince anyone to cherry-pick your patch back to stable/queens? | |
| 14:06:05 | cdent | mnaser: that _will_ get back ported | |
| 14:06:09 | cdent | jinx | |
| 14:06:12 | mordred | _awesome_ | |
| 14:06:14 | mnaser | cool | |
| 14:06:23 | mnaser | this seems to be relatively low touch | |
| 14:06:25 | mnaser | lets break stuff now | |
| 14:07:54 | mnaser | i guess there will be a merge conflict because it looks like placement exists in `nova/api/openstack/placement/` in queens but we can take care of that easily in the backport | |
| 14:11:18 | mnaser | mordred, cdent: https://review.openstack.org/#/c/575117/1 cherry-picked and i can see it in effect http://placement-ca-ymq-1.vexxhost.net/ | |
| 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 | |