Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-03-04
14:23:55 mordred brtknr: beautiful - thanks
14:26:13 mordred slaweq: https://review.opendev.org/#/c/711237/ look ok to you? also - I rechecked that description patch - it seems to just keep being unlucky
14:29:31 openstackgerrit Bharat Kunwar proposed openstack/openstacksdk master: Return uuid alias for coe_cluster in non strict mode https://review.opendev.org/710823
14:29:57 brtknr mordred: sorry, i had to fix the brackets out of OCD
14:33:10 mordred brtknr: I agree with your fix :)
14:33:55 brtknr mordred: :D
14:38:04 Shrews brtknr: thank you for the tests!
14:38:24 brtknr Shrews: my pleasure
14:55:44 slaweq mordred: looking
15:00:22 slaweq mordred: +2 this patch and thx for rechecking the other one :)
15:14:03 openstackgerrit Javier Peña proposed openstack/openstacksdk master: Replace assertItemsEqual with assertCountEqual https://review.opendev.org/711235
15:16:59 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Build utility image for using osc https://review.opendev.org/711246
16:15:10 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Build utility image for using osc https://review.opendev.org/711246
16:20:40 openstackgerrit Bharat Kunwar proposed openstack/openstacksdk master: Return uuid alias for coe_cluster in non strict mode https://review.opendev.org/710823
16:20:57 openstackgerrit Bharat Kunwar proposed openstack/openstacksdk master: Return uuid alias for coe_cluster in non strict mode https://review.opendev.org/710823
16:21:09 brtknr mordred: Shrews: Sorry i should have run tox -e pep8 before submitting
16:21:41 mordred brtknr: hahahaha
17:03:16 openstackgerrit Clark Boylan proposed openstack/python-openstackclient master: Replace pkg_resources with importlib-metadata https://review.opendev.org/661856
17:03:31 smcginnis Thanks mordred. Sad to see how many names are in the "no longer around" list.
17:03:47 mordred smcginnis: right?
17:04:07 smcginnis Just imagine if there were still that many cores working on things here. That OSC thread definitely wouldn't have been an issue.
17:04:18 dtantsur le sigh
17:04:38 mordred smcginnis: _seriously_
17:08:06 dtantsur ... and I'm not even officially assigned to work on SDK ...
17:09:52 smcginnis Heh, I'm not even officially assigned to work on OpenStack. I just have a hard time moving on. :D
17:10:02 dtantsur oh wow
17:10:42 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Add retired and retired_reason fields to baremetal node https://review.opendev.org/711032
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 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: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: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

Earlier   Later