| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-09-20 | |||
| 13:57:40 | AJaeger | ok, thanks | |
| 14:05:37 | openstackgerrit | Merged openstack/openstacksdk master: Update .zuul.yaml https://review.openstack.org/603563 | |
| 14:29:49 | openstackgerrit | LIU Yulong proposed openstack/openstacksdk master: Support firewall service for SDK https://review.openstack.org/592303 | |
| 15:08:19 | mnaser | mordred: i remember you mentioning there was a way to get an 'http client' for the placement service using openstacksdk :( | |
| 15:08:23 | mnaser | but i cant remember where or how | |
| 15:09:03 | mnaser | it was something that even if there is no placement support, doing something got you an http client | |
| 15:18:11 | mordred | mnaser: conn.placement should be an http client for placement | |
| 15:18:44 | mordred | mnaser: so conn.placement.get('/some/url') should return you a Response object | |
| 15:18:55 | mnaser | mordred: wonderful, i'll give that a shot. writing tooling to do an audit of placement/nova | |
| 15:19:33 | mordred | cool! we should probably add real placement support | |
| 15:19:46 | mordred | maybe one day I'll sucker cdent into doing that | |
| 15:19:51 | mnaser | mordred: mriedem made osc-placement so it cant be that much work | |
| 15:20:14 | cdent | andrey and a few others did a lot of that work | |
| 15:20:24 | cdent | mordred: curl and/or gabbi 4evah | |
| 15:23:42 | mnaser | mordred: http://paste.openstack.org/show/730447/ shucks | |
| 15:23:45 | mnaser | i remember us talking about this | |
| 15:23:53 | mnaser | maybe the fix wasn't released | |
| 15:24:04 | mnaser | cdent pushed up something about this too | |
| 15:25:51 | mriedem | yeah i only reviewed osc-placement... | |
| 15:26:11 | cdent | mnaser: you thinking of this: https://review.openstack.org/#/c/575117/ ? | |
| 15:26:32 | mriedem | cdent: no, | |
| 15:26:34 | mriedem | more about, | |
| 15:26:34 | mnaser | cdent: ah yes | |
| 15:26:47 | mnaser | this is a queens deployment | |
| 15:26:47 | mriedem | oh - i think what mnaser is looking for is a tool to look for orphans in placement | |
| 15:27:02 | mriedem | e.g. orphaned providers or allocations for things that don't actually exist in nova anymore | |
| 15:27:05 | mriedem | like compute nodes and instances | |
| 15:27:09 | mnaser | well that's what im trying to write if i get a working client :p | |
| 15:27:29 | cdent | it's fun to "yes" and "no" to the same thing | |
| 15:27:31 | mriedem | personally i think that should live in nova-manage placement * | |
| 15:27:51 | mordred | mnaser: ah - that hasn't landed yet :( | |
| 15:27:53 | mnaser | i dont mind adding that in | |
| 15:28:02 | mriedem | but as i said yesterday, we can't know if the providers/allocations in placement are for nova things really without consumer types | |
| 15:28:16 | mriedem | although we can probably glean that from knowing if the provider has VCPU inventory | |
| 15:28:35 | mordred | oh - wait - I can't read - it did land | |
| 15:28:39 | mriedem | (1) is it root (2) does it have vcpu inventory, then it's likely a compute node | |
| 15:28:54 | mnaser | mordred: landed on the API side in rocky, i dont think sdk works around this somehow locally | |
| 15:29:35 | mordred | mnaser: yah - I do not believe it has any local workarounds. we could maybe make one? I think the best workaround would be to put in a placement_endpoint_override | |
| 15:29:39 | mnaser | mriedem: i was going to assume it was a compute node all the time (because in my use case it always is) but i guess adding those stuff can be trivial | |
| 15:29:56 | mordred | in your clouds.yaml or whatever - so that we don't try to run discovery and fail due to lack of status | |
| 15:30:16 | mnaser | im totally using env variables out of lazyness | |
| 15:30:22 | mnaser | so i assume OS_PLACEMENT_ENDPOINT_OVERRIDE ? | |
| 15:30:46 | mordred | yah | |
| 15:32:24 | cdent | mriedem: speaking of "does it have vcpu inventory" I made https://review.openstack.org/#/c/600016/ in response to digging in some of the placement-db using nova-manage and nova-status stuff | |
| 15:33:23 | mnaser | mordred: yay that worked, i'll workaround with that and then maybe i'll ask for help from mriedem to bring that into nova-manage | |
| 15:33:36 | mordred | coolio | |
| 15:33:40 | mnaser | merci beaucoup | |
| 15:33:44 | mordred | \o/ | |
| 17:04:28 | edleafe | cdent: elmiko: dtantsur: https://etherpad.openstack.org/p/api-sig-newsletter is ready for your review | |
| 17:05:12 | dtantsur | looks good | |
| 17:07:47 | cdent | "has finally realized" more like "accepted" but yeah: looks good | |
| 17:08:51 | elmiko | edleafe: ++ lgtm | |
| 17:08:58 | edleafe | cdent: we all realized that about you much earlier :) | |
| 17:48:03 | elmiko | edleafe cdent , i enjoyed your writeups from the ptg, thanks! | |
| 18:02:18 | edleafe | dtantsur|afk: wish you could have been there too | |
| #openstack-sdks - 2018-09-21 | |||
| 00:57:14 | openstackgerrit | LIU Yulong proposed openstack/openstacksdk master: Support firewall service for SDK https://review.openstack.org/592303 | |
| 13:45:55 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Use discovery instead of config to create proxies https://review.openstack.org/600292 | |
| 13:57:15 | Shrews | +306, -1600 | |
| 13:57:18 | Shrews | wow | |
| 13:57:29 | Shrews | i can't wait to fully review that | |
| 13:57:40 | Shrews | while drinking | |
| 14:00:19 | mordred | Shrews: one of these days it's going to pass the bifrost job and I'm going to be happy | |
| 14:01:49 | mordred | Shrews: for now I've put in an autohold so I can poke at it again | |
| 14:02:04 | mordred | Shrews: I *thought* I'd figured out the issue 2 days ago ... sigh | |
| 14:11:01 | Shrews | mordred: i'm sort of waiting for all green before i look at it | |
| 14:11:15 | mordred | it's the best bet | |
| 14:12:33 | dtantsur | on one hand, bifrost is pita :) on the other - it's the only thing that apparently provides this sort of coverage | |
| 14:14:54 | mordred | dtantsur: yah - I've been adding unit tests as I figure out issues - but apparently there's still one I don't have : | |
| 14:14:56 | mordred | :( | |
| 14:15:37 | mordred | dtantsur: it's been really useful to sort out the no-catalog versioned and unversioned endpoint use-case :) | |
| 14:17:22 | dtantsur | oh yeah | |
| 14:17:49 | dtantsur | mordred: unrelated: do you plan on openstacksdk release any soon? I could give switching metalsmith to it a try | |
| 14:20:37 | mordred | dtantsur: yes - I think we're ready for one - but I was gonna see if I could get that discovery patch landed | |
| 14:20:49 | dtantsur | right | |
| 14:21:13 | mordred | dtantsur: but if it doesn't turn green today, maybe we'll cut a release with what we have so far on monday | |
| 14:34:50 | dtantsur | yeah, and then another one. release numbers are cheap :) | |
| 14:43:32 | mordred | ++ | |
| 14:48:04 | mordred | Shrews: if you're bored and feel like flaying your brain a little ... https://review.openstack.org/#/c/603739/ | |
| 14:48:41 | Shrews | k k | |
| 14:50:35 | mordred | Shrews: I think we might want corvus to review it when he gets back as well - since it's a fundamental change to the internals of the task manager - but I *think* it's solid | |
| 14:51:19 | Shrews | passed pep8... ship it | |
| 14:52:49 | mordred | ++ | |
| 15:49:30 | Shrews | mordred: why the call to ret.exception()? We don't seem to do anything with it | |
| 15:50:15 | Shrews | ret.result() should raise an exception if one occurred in the call (if i read the Futures docs correction) | |
| 15:50:23 | Shrews | s/correction/correctly/ | |
| 15:54:10 | mordred | Shrews: oh - I couldn't find mention that result would do that - so I guess it's senseless | |
| 15:54:36 | Shrews | mordred: https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.result | |
| 15:55:28 | mordred | Shrews: so, whatyou're saying is thatif I could actually read simple english, my life would be better? | |
| 16:07:23 | Shrews | mordred: left comments :-P | |
| 16:08:43 | mordred | Shrews: \o/ | |
| 16:09:31 | Shrews | mordred: i'm not sure if anyone actually uses submit_function_async(), but probably a bad idea to totally remove an API call | |
| 16:09:38 | Shrews | correct me if i'm wrong | |
| 16:09:49 | Shrews | 'cause i know nothing about anything | |
| 16:09:54 | Shrews | 'cause Friday | |
| 16:10:17 | mordred | Shrews: yeah - I agree with you in principle, but in practice I'm 99.9% sure that nodepool is the only consumer of anything related to taskmanager | |
| 16:10:29 | Shrews | i checked nodepool for it, fwiw | |
| 16:10:31 | Shrews | not used | |
| 16:10:34 | mordred | yah | |
| 16:10:39 | Shrews | so i can be convinced to remove it | |
| 16:11:01 | Shrews | mmmm, frothy | |