| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2020-03-04 | |||
| 17:11:17 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Add retired and retired_reason fields to baremetal node https://review.opendev.org/711032 | |
| 17:20:58 | mordred | dtantsur: I've *never* been officially assigned to work on SDK ;) | |
| 17:21:05 | dtantsur | LOOOL | |
| 17:37:28 | umbSublime | Is it possible to specify microversion to use on openstack.proxy.Proxy calls. Or at least force one to be used by the proxy. I know I've asked this in the past, but it wasn't possible then. Maybe it is now ? | |
| 17:41:30 | umbSublime | I still get None on for example conn.compute.min_version and conn.compute.max_version yet information is there when inspecting: conn.compute.get_all_version_data() | |
| 17:43:43 | umbSublime | openstack.version.__version__ == 0.41.0, keystoneauth1.__version__ == 3.18.0 | |
| 17:44:17 | mordred | umbSublime: the intent is that as a user of the library you should never have to specify a microversion - let me look at the min_version / max_version thing ... what are you trying to do that isn't working? (other than specifying a microversion) | |
| 17:44:59 | mordred | (I believe we did add the ability for you to force one - but I'm more curious why you need to) | |
| 17:47:55 | umbSublime | Well say I cann conn.compute.hypervisors(), then the 'id' is an int while when using microversion 2.53 I get UUIDs. Same can be observed with openstackclient: `openstack hypervisor list` vs `openstack --os-compute-api-version 2.53 hypervisor list` | |
| 17:49:05 | umbSublime | I can force it with conn.compute.get('/os-hypervisors', microversion="2.53"). But it would be awesome if i could do conn.compute.hypervisors(microversion="2.53") | |
| 17:49:40 | mordred | should we not maybe just default to 2.53 if it's available in this case? | |
| 17:50:01 | umbSublime | yes or whatever the max_microversion is for the endpoint | |
| 17:51:26 | mordred | well - we have to pick max_microversion we can support- this doesn't sound like one we'd need to update anything else in the sdk to support, so it's pretty easy (sometimes thigs change key names or the liek and we need to add compat code to be able to safely provide them) | |
| 17:52:19 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Set max_microversion to 2.53 for hypervisors https://review.opendev.org/711294 | |
| 17:52:26 | umbSublime | so then each api call requiring a specific microversion should be hard-coded on sdk side ? | |
| 17:52:31 | mordred | umbSublime: ^^ that should do the trick for you | |
| 17:52:47 | mordred | umbSublime: yes - otherwise microversion changes don't protect the user from very much and we might as well not have them | |
| 17:52:54 | mordred | but if we use them well, they're pretty awesome | |
| 17:53:29 | mordred | we don't hard-core the api calls themselves, we have a system where we can express what microversion a given resource knows how to handle the requests and responses for | |
| 17:53:58 | umbSublime | Ahh I see. | |
| 17:54:40 | umbSublime | Regardless of that though in the event that new microversion is not yet supported by SDK, wouldn't it be also pretty neat to be able to specifiy it as kwarg on the method too ? | |
| 17:55:32 | umbSublime | Because there are cases where a feature is supported between microverion X and Y and then removed or again modified in microversion Z | |
| 17:55:42 | mordred | not necessarily, because the SDK has to map the responses into the Resource objects. that said - I'm _pretty_ sure if you set compute_api_version to 2.53 in our clouds.yaml then we'll set default_microversion of it | |
| 17:56:03 | mordred | umbSublime: oh that's joyous :) | |
| 17:56:22 | umbSublime | mordred, I'll give that a shot | |
| 17:56:30 | mordred | dtantsur|afk: darn, you're not here- we added support for configuring a defaut_microversion override didn't we? | |
| 17:57:17 | mordred | yes | |
| 17:57:32 | mordred | umbSublime: so you can either be _explicit_ and do compute_default_microversion=2.53 | |
| 17:57:51 | mordred | or you can do compute_api_version=2.53 and we'll infer that you mean default_microversion | |
| 17:58:27 | mordred | however - just know that your mileage may vary if you do that - we may not necessarily know how to deal with all of the responses on all of the calls and it could blow up in fascinating ways :) | |
| 17:58:53 | mordred | (always looking for improvements though - so if you do find a place where you do that and it blows up, let us know and we can figure out how to support that mv) | |
| 17:59:00 | umbSublime | indeed forcing compute_api_version in clouds.yaml does the job. | |
| 17:59:24 | umbSublime | I wasn't aware of that trick. Very useful!! | |
| 18:00:16 | mordred | woot! | |
| 18:00:34 | umbSublime | ^^ | |
| 18:01:40 | umbSublime | Am I correct in assuming that if I set compute_default_microversion=2.53, then the microversion header will be sent to ALL compute requests ? | |
| 18:01:51 | mordred | yes | |
| 18:01:57 | umbSublime | \o/ | |
| 18:02:07 | mordred | well - all compute requests where sdk isn't already setting something more explicitly | |
| 18:02:34 | umbSublime | right, like for example the patch on hypervisors you just did ? | |
| 18:02:39 | mordred | there are places with more explicit mv negotiation - live_migrate comes to mind | |
| 18:02:49 | mordred | and yeah | |
| 18:03:20 | mordred | so like I said - the GOAL is that you never have to do that - but we're obviously not 100% there on that goal | |
| 18:03:51 | umbSublime | Asside from debug log and reading the code, is there a programatic way to know what API version will be used by conn.compute.<method> ? | |
| 18:04:08 | mordred | that's an excellent question | |
| 18:04:17 | umbSublime | Well for me this clouds.yaml trick fixes a lot of headaches !! | |
| 18:04:35 | mordred | I'm gonna say - "no" ... but I think that's an excellent thing to want to know | |
| 18:04:48 | mordred | so I'll think about how we might accomplish that | |
| 18:06:37 | umbSublime | mordred, thanks a lot ! | |
| 18:07:32 | openstackgerrit | Merged openstack/openstacksdk master: Replace assertItemsEqual with assertCountEqual https://review.opendev.org/711235 | |
| 18:19:24 | mordred | slaweq: if you have a sec, https://review.opendev.org/#/c/710030/ is neutron related | |
| 18:20:01 | mordred | slaweq: as is https://review.opendev.org/#/c/710820/ | |
| 18:47:36 | mordred | dtantsur|afk: whence you are back - I'm looking at switching to futurist ... we use concurrent.futures.as_completed currently - futurist seems to have wait_for_all and wait_for_any ... do you have a suggestion of the best way to accomplish a similar pattern to as_completed? | |
| 18:48:16 | mordred | dtantsur|afk: hrm. actually - looking at the code wait_for_all should still work | |
| 18:50:15 | mordred | dtantsur|afk: ACTUALLY - nothing shoudl stop us from using concurrent.futures.as_completed since futurist is using that as a base | |
| 18:56:12 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Switch to futurist for concurrency https://review.opendev.org/711301 | |
| 19:29:28 | umbSublime | discussed here in the past (don't remembeer who). i had a work-around where I added a placement adapter to keystoneauth, but it was a bit dirty | |
| 19:29:28 | umbSublime | I just watched a talk from OS summit about the SDK. The speaker says a proxy object is created for every service_types_authority even if the target cloud doens't have the service in it's endpoints and even if no ressource objects are created (we should at least be able to get/put/post/delete). Has this been rolled back ? I have placement-api in my deployment but get and error with conn.placement. This is also something i've | |
| 19:30:46 | mordred | umbSublime: WELL - that was probably me, and you should always take anything I say with a grain of salt | |
| 19:31:39 | mordred | that said - I could expect conn.placement to exist and be a proxy - how ever, if you don't have placement in your service-catalog, it's not going to know how to configure that proxy to be able to talk to anything because it's not going to know where the placement endpoint is | |
| 19:32:12 | mordred | umbSublime: you can put placement_endpoint_override in your clouds.yaml with the placement endpoint and that should tell it where your placement service is | |
| 19:32:23 | umbSublime | I do see it with `openstack endpoint list` | |
| 19:32:30 | mordred | ok. so it is in your catalog | |
| 19:32:36 | umbSublime | yup | |
| 19:32:53 | mordred | in that case I fully expect conn.placement to give you a working proxy | |
| 19:33:26 | umbSublime | Any debug or things you want me to check (I assume there might be a bug) | |
| 19:33:45 | umbSublime | Great talk BTW :D | |
| 19:33:47 | openstackgerrit | James Denton proposed openstack/openstacksdk stable/stein: Add "name" filter in "list" call when retrieving a single register https://review.opendev.org/711314 | |
| 19:37:06 | umbSublime | mordred, here is the stack-trace what the stacktrace looks like: https://hastebin.com/vizuhufiqi.rb | |
| 19:37:09 | mordred | umbSublime: can you run http://paste.openstack.org/show/790311/ (obviosly change the connect call if you need to) and paste the output? | |
| 19:37:30 | mordred | oh - hrm | |
| 19:37:45 | mordred | what version of keystoneauth - and do you know what version of placement? | |
| 19:38:29 | umbSublime | keystoneauth1.__version__ == '3.18.0 | |
| 19:38:55 | umbSublime | :facepalm: I didn't install osc-placement in that venv. potential pebcak | |
| 19:39:17 | mordred | possibly - however ... are you setting a placement_api_version there? | |
| 19:40:09 | umbSublime | Ok so I get same stack-trace with osc-placement installed. And I have nothing related to placement in my clouds.yaml | |
| 19:41:13 | mordred | yeah - I think this is placement not returning a proper version discovery doc for some reason - which is a thing I thought we'd put in a workaround for before | |
| 19:41:36 | mordred | could you run that little script above? that should catch the full http trace | |
| 19:42:40 | umbSublime | being an private cloud do you mind If I just remove endpoint dict from the output i share with you ? (that's probably what you want to check :/ ) | |
| 19:43:31 | mordred | nah - actually I thnk that's fine - I mostly want to see the payload returned from the root of your placement service | |
| 19:43:56 | umbSublime | After the token request i see a call on the endpoint with the port my placement-api is running on. This is the response: {"versions": [{"min_version": "1.0", "max_version": "1.17", "id": "v1.0"}]} | |
| 19:44:10 | mordred | sigh | |
| 19:44:44 | mordred | ok. so - that's a broken discovery dict - which I *think* we got fixed in upstream placement (I'll go check that next - it doesn't match my test fixture for placement) | |
| 19:44:51 | umbSublime | Is this correct response format? | |
| 19:44:53 | mordred | for now - set placement_endpoint_override | |
| 19:44:55 | mordred | yeah | |
| 19:44:58 | mordred | it's jst missing a status: field | |
| 19:45:04 | umbSublime | Ahh so then i'd need to update my placement-api service | |
| 19:45:18 | mordred | yeah - although I *also* want to see if I can't work around that in sdk too | |
| 19:45:25 | mordred | because that's a bad experience for people | |
| 19:45:33 | mordred | I thought we already had - but I see clearly we didn't | |
| 19:45:50 | mordred | but for now - if you set placement_endpoint_override to the base endpoint of the placement service it should work for you | |
| 19:45:53 | umbSublime | would be awesome. For newer clouds, I can update the version, but this legacy cloud will probably have to live with it's current placement version | |
| 19:45:58 | mordred | yah | |
| 19:46:00 | umbSublime | testing now | |
| 19:46:09 | mordred | and we aim to support older clouds too - so it's fair for us to deal with that | |
| 19:46:35 | umbSublime | I put the endpoint I get for `endpoint list` as a value right ? | |
| 19:46:43 | mordred | yeah | |
| 19:47:55 | umbSublime | \o/ print(conn.placement) -> <openstack.proxy.Proxy object at 0x7ffbdaf5a5c0> | |
| 19:47:58 | mordred | WOOT | |