| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2020-03-06 | |||
| 10:31:47 | openstackgerrit | Tom Stappaerts proposed openstack/python-openstackclient master: Support for stateless security groups https://review.opendev.org/711515 | |
| 11:16:58 | LarsErikP | did some more testing. Seems like SDK 0.27 acutally will fix the issue. Who should I nudge to get that released in UCA? | |
| 11:22:19 | frickler | LarsErikP: you can create a bug against UCA in lp or ping coreycb+jamespage in #ubuntu-server | |
| 11:29:41 | LarsErikP | frickler: fantastic! thaks :) | |
| 11:29:44 | LarsErikP | thanks* | |
| 11:29:56 | LarsErikP | god damn. Can't even spell easy words now... #friday | |
| 12:28:06 | openstackgerrit | Tom Stappaerts proposed openstack/openstacksdk master: Support for stateless security groups https://review.opendev.org/711513 | |
| 12:54:25 | openstackgerrit | Tom Stappaerts proposed openstack/python-openstackclient master: Support for stateless security groups https://review.opendev.org/711515 | |
| 13:57:38 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Add retired and retired_reason fields to baremetal node https://review.opendev.org/711032 | |
| 13:58:20 | openstackgerrit | James Denton proposed openstack/openstacksdk stable/train: Include "fields" to "SecurityGroup" query parameters https://review.opendev.org/711622 | |
| 14:01:12 | amotoki | vishakha: cmurphy's suggestion works for me. | |
| 14:01:48 | vishakha | amotoki: Thanks for the response. | |
| 14:02:09 | amotoki | vishakha: I originally advised to follow the OSC convention for boolean opts, then you proposed --enable/disable-ignore-foo, I suggested to avoid verb-verb style and finally you proposed the current version. | |
| 14:02:28 | amotoki | vishakha: during this, the route went wrong a bit.... :( | |
| 14:03:06 | vishakha | amotoki: Yes I agree. | |
| 14:03:45 | openstackgerrit | Tom Stappaerts proposed openstack/openstacksdk master: Support for stateless security groups https://review.opendev.org/711513 | |
| 14:16:20 | mordred | brtknr: openstack.tests.functional.cloud.test_cluster_templates.TestClusterTemplate and openstack.tests.functional.cloud.test_magnum_services.TestMagnumServices ... so not many :) | |
| 15:16:57 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Extract check temp_url_key logic https://review.opendev.org/710973 | |
| 15:16:58 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: [WIP] Import generate_temp_url from swiftclient https://review.opendev.org/711640 | |
| 16:51:05 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add ansible stable-2.9 job and run 2.8 and 2.9 https://review.opendev.org/711471 | |
| 16:51:58 | umbSublime | Hi again, bouncing back on the issue we fixed related to microversion on the compute.hypervisor and the work-around of adding `compute_api_version: <target_MV>` in clouds.yaml. I noticed it works as expected with the SDK, but the OSC doesn't seem to pick it up. (I still get id=type(int) and not id=type(uuid)). I only get the header `-H "X-OpenStack-Nova-API-Version: 2.53"` added when I use --os-compute-api-version=2.53 | |
| 16:56:51 | umbSublime | `openstack 5.0.0` | |
| 17:51:44 | mordred | umbSublime: well - joy | |
| 17:53:02 | umbSublime | no biggie, just wanted to point it out | |
| 17:55:15 | mordred | umbSublime: that'll be a little longer to sort out - but it's actually an important one to do. I'm goign to see if there's a quicker way to plumb those through than what my hunch is | |
| 17:56:00 | umbSublime | Yah I figured this one would be a bit trickier. Would you like me to file a bug for tracking this ? | |
| 17:57:49 | mordred | sure! | |
| 17:59:18 | umbSublime | I'll get to it a bit later today ;) | |
| 18:00:48 | umbSublime | I'm building my first cliff app right now, and I'm not sure how to access to apps parser from within a command (or if that's even possible). cmd_obj.get_parser() only returns the parser local to the command. | |
| 18:06:52 | umbSublime | Welp, again I asked a question too quick. I can use cmd_obj.app_args to access the parsed args | |
| 18:08:43 | mordred | woot! | |
| 18:10:24 | umbSublime | I want to centralize all my "operator" scripts under a CLI. I'm still debating if I want a standalone CLI, or an OSC plugin. In any case transitioning for a stand-alone CLI to OSC plugin seems very easy | |
| 18:17:24 | openstackgerrit | Monty Taylor proposed openstack/python-openstackclient master: Honor api config version for compute calls https://review.opendev.org/711732 | |
| 18:18:07 | mordred | umbSublime: ^^ that fixes the _specific_ issue - but obviously this is a thing that should be generalized and apply to all of the osc config reading | |
| 18:43:53 | rm_work | mordred: did chances for a release get sidetracked due to a bug yesterday? :D | |
| 18:44:42 | mordred | rm_work: yeah. I think we've landed all the patches now - but I think it'll be first thing monday before the release team will cut a release (they don't tend to release on friday) | |
| 18:44:52 | rm_work | kk, WFM | |
| 18:55:55 | umbSublime | mordred, I applied the patch, but I still get `-H "X-OpenStack-Nova-API-Version: 2.1` | |
| 19:01:19 | mordred | umbSublime: boo. it worked for me locally ... | |
| 19:01:49 | umbSublime | Should we populate L40's _compute_api_version. If not it will always evaluate to None | |
| 19:03:49 | mordred | no - I think it gets populated in check_api_version | |
| 19:04:02 | umbSublime | Is it this call that looks in the config `instance._cli_options.get_default_microversion(API_NAME)`? | |
| 19:05:02 | mordred | yeah - that one and the one before it - get_api_version will get it if you set compute_api_version and get_default_microversion gets compute_default_microversion | |
| 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 | |