Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-03-05
17:34:52 dtroyer smcginnis: I recall that exact discussion previously, I think in Vancouver. I was a bit distracted that week by the introduction of stalingx so I don't recall the particulars. I do agree that keeping those things distinct is important to make community-wide progress
17:35:29 mordred brtknr: I havne't - go for it!
17:36:07 mordred smcginnis: yeah - I think the most important thing is keeping them distinct - otherwise it's too much
17:36:59 mordred smcginnis: I could see value in both directions - there's value in sdk-parity-first - because that also allows exposing to things like ansible and salt- but it has the drawback of not increasing tim bell's happiness
17:38:20 mordred doing osc-parity first would make tim bell happy and would likely be less work for a chunk of people (I think therea re more people with osc plugins than people with comprehensive sdk code) ... but it might result in increasing the surface area of work for a future "now convert osc plugins to sdk" - since there would potentially be _more_ osc plugin code to convert
17:38:55 smcginnis True. But seems like it could make it a little easier for some folks if that got done.
17:39:02 mordred smcginnis: I honestly don't know which I think is the better choice - or would give people the greatest amount of "job well done" satisfaciton
17:39:12 smcginnis And part of my thought was avoiding that extra work too.
17:39:13 mordred yeah
17:39:55 smcginnis Honestly, I'd rather not have a cycle goal for it and just have a clear plan to work towards. Then when things get closer to actually being something that could even be accomplished in one cycle, then make it a goal.
17:43:23 mordred smcginnis: ++
17:43:26 mordred I thnk very much that
18:04:57 openstackgerrit Bharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526
18:04:59 brtknr mordred: Shrews ^
18:06:48 mordred brtknr: cool. also - please see mailing list - I mayhave just mentioned you ...
18:08:21 brtknr mordred: will do
18:08:45 brtknr btw why is the json encapsulated inside baybodel= in https://review.opendev.org/#/c/711526/1/openstack/tests/unit/cloud/test_coe_clusters.py line 66
18:09:45 mordred brtknr: the validate parameter is for validating json sent to the api call
18:10:06 mordred the normal json parameter is for specifying what the fake http call should return
18:10:39 brtknr the fake http call should return a thing without the baymodel bit
18:10:52 mordred oh- I get yourquestion now
18:11:13 mordred it's entirely possible it's a bug in the test then
18:11:25 brtknr and the validate part i removed because it didnt seem to matter whether it was there or not
18:11:50 mordred brtknr: we might want to keep the validate portion though - the call will still work - but you can see the results if you change the contents of it it should break
18:12:08 mordred it's testing the other side of the interaction - that the sdk call produces the correct payload to send to the server
18:12:36 mordred it's probably not super important in this case since we're not really transforming the input
18:13:59 brtknr ah makes sense
18:30:05 brtknr mordred: here's the weird thing, if i remove the baymodels= in the GET requests, tox -e py36 fails as it expects baymodels= part to be there
18:30:25 brtknr but in post requests, it would rather it was not there
18:38:49 mordred brtknr: does magnum not have a top level baymodels: [] in its list response?
18:39:19 mordred brtknr: https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=list-all-baymodels-detail#id34
18:39:46 mordred brtknr: GET /baymodels returns {'baymodels': [ {}, {} ] }
18:39:58 mordred so we need the baymodels= there
18:40:49 mordred I agree - inthe response for the POST - there should be no top level baymodel or baymodels
18:40:56 mordred nor in teh request
18:41:06 mordred https://docs.openstack.org/api-ref/container-infrastructure-management/?expanded=create-new-baymodel-detail#id25
18:55:25 brtknr mordred: nice to see it confirmed
18:56:32 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix service_type test for magnum in gate https://review.opendev.org/711533
18:56:52 openstackgerrit Bharat Kunwar proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526
18:56:52 mordred brtknr, Shrews: ^^ that should fix the magnum tests in the gate
18:57:54 brtknr Wow thats a mouthful, I did not know that
18:57:55 mordred (711533 that is)
18:58:11 Shrews mordred: are we taking bets that the tests still work? ;)
18:58:21 mordred Shrews: nope!
18:58:35 mordred Shrews: but - they should at least RUN now and fail as tests :)
18:58:40 mordred brtknr: https://service-types.openstack.org/service-types.json
18:59:15 mordred or more specifically: https://opendev.org/openstack/service-types-authority/src/branch/master/service-types.yaml#L41
18:59:38 mordred for normal users it should work to refer by official type or any of the aliases
18:59:46 mordred but we wrote the has_service to be strict :)
19:08:47 brtknr mordred: ouch
19:30:57 mordred yah
20:56:03 umbSublime Hey another quick question related to os-client-config. I just noticed from the README that it was superceded by the sdk, but I'm not sure how I can reproduce even a basic call like `os_client_config.OpenStackConfig().get_all_clouds()` I just want to have an object representing the clouds.yaml without having to parse it myself
21:02:19 umbSublime derr nvm just found it under openstack.config ...
21:08:14 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Set max_microversion to 2.53 for hypervisors https://review.opendev.org/711294
21:09:23 mordred umbSublime: \o/
21:09:42 mordred umbSublime: yeah - os_client_config moved to openstack.config ... perhaps we should update the readme to point more specifically
21:11:16 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Normalise create_coe_cluster{,_template} results https://review.opendev.org/711526
21:12:27 mordred Shrews, brtknr: my patch above fixed the magnum functional tests - so I added a depends-on between brtknr's patch and mine so we can make sure that doesnt' break functional tests (I'm pretty sure it's ok - but we have green functional tests - so why not!)
21:32:22 umbSublime tbh If I would've searched 2 minutes more before posting, it would've been fine. It wouldn't hurt though. (btw thanks for updating topic on the chan)
21:56:55 umbSublime is cliff also maintained by the SDK team ?
22:13:24 Shrews no
22:14:09 mordred Shrews: well ...
22:14:56 mordred umbSublime: there is a proposal up to merge the sdk and osc teams - so assuming that goes through (there is currently no dissent) the answer becomes "yes"
22:15:43 Shrews osc team maintained cliff? heh
22:16:06 Shrews TIL
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 :)

Earlier   Later