Earlier  
Posted Nick Remark
#openstack-sdks - 2020-03-06
19:05:30 mordred I'm curious why it didn't work for you but it did work for me
19:05:52 mordred do you have any env vars set like OS_COMPUTE_API_VERSION or anything?
19:06:35 umbSublime I have this is my config "compute_api_version: 2.53", no Env vars
19:07:27 umbSublime I fall in the `if` on L53
19:07:57 mordred oh. interesting
19:08:09 mordred so you have something in compute_api_version by there
19:10:42 umbSublime Both instance._cli_options.get_api_version(API_NAME) and instance._cli_options.get_default_microversion(API_NAME) return None
19:11:18 mordred OH
19:11:25 mordred it works for me without that patch
19:11:32 umbSublime compute_api_version --> API Version Major: 2, Minor: 1
19:11:52 mordred I think I may know what the issue is
19:12:01 umbSublime What config param did you use `compute_default_microversion` or `compute_api_version` ?
19:12:16 mordred compute_api_verison ... but I think there is a different issue
19:12:31 mordred I think your nova has the discovery document auth protected
19:12:58 mordred can you try making a bare curl GET call to your compute endpoint?
19:13:27 umbSublime I the bare endpoint discovery works, but if I add /v2.1 I get 401
19:13:32 mordred yeah. that's it
19:13:40 umbSublime wow
19:13:43 mordred we fixed the bug in nova the last cycle I think - and we work around it in sdk
19:14:06 mordred the novaclient that osc is using can't fetch your discovery document
19:14:16 umbSublime ishh, I'm sorry for the waste of time. I should've tested in a fresh venv with everything up to date
19:14:39 mordred no - it's the service ... I think this is something we're working around in sdk but not in osc
19:14:45 mordred so a fresh venv won't fix it for you
19:14:54 umbSublime Ahh ok I get what you mean now
19:15:23 mordred I think what we need to do in osc is to replace the contents of check_api_version with the sdk equiv
19:15:34 mordred since that knows how to do discovery even with a broken nova service
19:16:26 mordred I'll work on getting that - might take me a few - but also should fix nova across the board for OSC
19:17:10 umbSublime +1 !!, I'll try and document the result of our discussion in the bug
19:17:13 mordred I think the difference is that --os-compute-api-version is hard-setting the value and ignoring discovery
19:17:15 mordred thanks!
19:18:18 umbSublime Thank you ! Through all our discussions in the last few days I learned so much about the SDK's and OSC's inner workings !
19:20:46 mordred yay! what a successful week then!
19:39:38 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Honor api version settings in config like CLI https://review.opendev.org/711732
19:40:04 mordred umbSublime: ^^ can you try that and see if it fixes the issue for you when you set the compute_api_version on the CLI?
19:40:06 mordred gah
19:40:10 mordred in the clouds.yaml
19:40:44 mordred it injects the value into the stream similarly to how it works with --os-compute-api-version which WAS working for you
19:44:22 umbSublime I'll give it a shot shortly and report back
19:49:39 umbSublime Before and after the patch `print(version_opt)` returns 2.1 (to make sure it's not a lib version issue let me just test in fresh venv)
19:50:11 mordred so weird
19:51:06 umbSublime Sobasically i don't enter the patch because `version_opt = str(self.cloud.config.get(option, default_version))` appears to be setting the value to '2.1'. Where does that 'default_version' come from
19:55:35 mordred oh. that is weird ... let me see
19:56:29 mordred ah. it's in the compute module
19:56:41 mordred but why does the cli arg work
19:57:39 mordred it's possible it's too late in the week to fully wrap my head around this :)
19:59:14 mordred umbSublime: actually ...
20:00:06 mordred so - in that line you just referenced ...
20:00:24 mordred option should be "compute_api_version" right?
20:01:06 mordred if you print self.cloud.config it should be a dict - and if you have compute_api_version in your clouds.yaml it should have compute_api_version in that dict - which means that line _should_ be returning your setting and not the default fallback value
20:15:18 umbSublime checking now, (sorry was AFK)
20:16:22 mordred no worries!
20:17:03 mordred thanks for trying out all the things :)
20:17:25 umbSublime option isn't in the dic, so the the .get returns default_version
20:18:28 umbSublime I see though that for other services I get and int. for example for identity Option=3
20:20:47 umbSublime herr nvm I did this without thinking
20:21:01 umbSublime I didn't notice option wasn't the key name, but a var containing the key name
20:25:03 umbSublime mordred, here is self.cloud.config -> https://hastebin.com/ugiketotup.py
20:25:39 mordred wow. yeah - that sure doesn't have compute_api_version in there
20:25:47 mordred you sure it's in your clouds.yaml?
20:27:16 mordred http://paste.openstack.org/show/790413/
20:27:17 umbSublime https://hastebin.com/ifulonekaq.cpp
20:27:19 mordred there's mine
20:27:48 umbSublime vexx <3
20:28:33 mordred you're calling this like openstack --os-cloud=ucne1 hypvisor list
20:29:42 umbSublime no :(, with env_var OS_CLOUD_CONFIG_NAME=ucne1
20:29:59 mordred that shold still be fine - do you have the other things set via env vars?
20:30:33 umbSublime nothing related to OS_COMPUTE_API_VERSION
20:31:03 umbSublime Just noticed I also have `OS_REGION_NAME=ncsa-east-ne1`, but I don't think that should cause issues
20:31:32 mordred oh wait ... no, OS_REGION_NAME is still a selector and fine
20:31:33 mordred BUT
20:31:39 umbSublime it works with --os-cloud though :O
20:31:42 mordred change OS_CLOUD_CONFIG_NAME=ucne1 to OS_CLOUD=
20:31:55 mordred change OS_CLOUD_CONFIG_NAME=ucne1 to OS_CLOUD=ucne1
20:32:11 umbSublime 'compute_api_version': '2.53',
20:32:16 mordred \o/
20:32:43 mordred now does the hypervisor list work without --os-compute-api-version ? (eithe with or without that patch)
20:32:57 umbSublime works with the patch, let me check without
20:33:52 umbSublime :facepalm: it works without the patch. It was env all along :/
20:33:56 mordred yay!
20:34:09 mordred well - still ... there are some things here I want to refactor :)
20:34:24 mordred but even better ... now we don't have to get any patches released for you
20:34:34 umbSublime XD
#openstack-sdks - 2020-03-07
18:57:26 openstackgerrit Merged openstack/python-openstackclient master: Add bindep file https://review.opendev.org/711055
#openstack-sdks - 2020-03-09
10:51:23 brtknr mordred: any idea when openstack modules will be removed from upstream ansible and users will need to wholly rely on collections?
11:56:06 rm_work mordred: going to be good to make an SDK release today you think? :D
12:59:43 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Extract check temp_url_key logic https://review.opendev.org/710973
13:10:37 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: [WIP] Import generate_temp_url from swiftclient https://review.opendev.org/711640
14:25:04 mordred rm_work: yes!
14:25:25 mordred brtknr: not sure when exactly, but it should be done by the 2.10 release
14:26:58 brtknr mordred: is there a deprecation notice for this somewhere?
14:31:23 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Set max_microversion to 2.53 for hypervisors https://review.opendev.org/711294
14:48:38 mordred slaweq: neutron change for you: https://review.opendev.org/#/c/711513/
14:49:14 slaweq mordred: sure, looking
14:55:26 mordred brtknr, rm_work: remote: https://review.opendev.org/711932 Release 0.42.0 of openstacksdk
14:55:41 rm_work thanks :)
14:56:39 brtknr mordred: yay
15:09:21 slaweq mordred: I just commented in https://review.opendev.org/#/c/711513/
15:17:20 mordred slaweq: oh good point on the request-side
15:17:51 mordred that seems like something we should add a more general feature to the neutron proxy / resources for
15:18:17 mordred "query_parameter, requires_extension='blah'" ... or something.

Earlier   Later