| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2020-03-05 | |||
| 22:23:43 | brtknr | What does the magnum job do out of interest? | |
| 22:24:09 | mordred | brtknr: it makes sure that there is a magnum running in the devstack and then runs the openstacksdk functional tests against that devstack | |
| 22:24:24 | mordred | brtknr: so - you can totally add magnum related functional tests and they'll run in that job | |
| 22:25:16 | mordred | obviously nested virt makes doing a _lot_ in functional tests somewhat heavy weight - so I don't think we have many magnum related functional tests today | |
| #openstack-sdks - 2020-03-06 | |||
| 00:23:49 | openstackgerrit | Merged openstack/openstacksdk master: Fix service_type test for magnum in gate https://review.opendev.org/711533 | |
| 00:27:41 | openstackgerrit | Merged openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526 | |
| 05:44:52 | brtknr | mordred: hmm I don’t see any functional tests for magnum, am I looking in the wrong place? | |
| 05:44:52 | brtknr | mordred: hmm I don’t see any functional tests for magnum, am I looking in the wrong place? | |
| 07:04:40 | vishakha | amotoki: Regarding https://review.opendev.org/#/c/697444/. Could you please look over the cmurphy's suggestion, so that I can proceed further on the patch. | |
| 07:42:43 | LarsErikP | Hi guys! Spoke to johnsom over at #openstack-horizon about a thread issue i'm having with octavia-dashboard in stein. He was pretty sure this patch fixed it: https://review.opendev.org/#/c/695795/ | |
| 07:44:05 | LarsErikP | But I'm a little bit confused, because: I have one horizon-server running 16.0.0 (train) and sdk 0.36.0 which does not have the issue; and one server running 15.1.1 and sdk 0.26.0 which has this issue. The confusion is, neither of those SDK versions has the aforementioned patch included... | |
| 07:45:01 | LarsErikP | The issue is basically that leaving a browser open at the list of load-balancers will accumulate threads on the horizon server, and eventually kill the server.. | |
| 07:59:21 | LarsErikP | and; I tried to "ninja-apply" that patch into my horizon-server running 15.1.1 and SDK 0.26.0, but I stil got the issue - so I guess there is more to this? | |
| 09:19:51 | openstackgerrit | Tom Stappaerts proposed openstack/openstacksdk master: Support for stateless security groups https://review.opendev.org/711513 | |
| 10:15:06 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Add retired and retired_reason fields to baremetal node https://review.opendev.org/711032 | |
| 10:15:42 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Add retired and retired_reason fields to baremetal node https://review.opendev.org/711032 | |
| 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 | |