Earlier  
Posted Nick Remark
#openstack-sdks - 2020-03-05
22:22:32 brtknr mordred Shrews: thanks for the merge!
22:22:44 brtknr glad you fixed the ci too!
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)

Earlier   Later