Earlier  
Posted Nick Remark
#openstack-sdks - 2020-03-10
17:46:21 openstackgerrit Merged openstack/openstacksdk master: Fix aggregate functional test for id restriction https://review.opendev.org/712068
18:19:39 mordred woot
19:27:03 openstackgerrit Merged openstack/openstacksdk master: Consistent normalization of Machine objects in the cloud layer https://review.opendev.org/711952
19:53:47 openstackgerrit Merged openstack/openstacksdk master: Support for stateless security groups https://review.opendev.org/711513
#openstack-sdks - 2020-03-11
07:17:32 openstackgerrit Bram Verschueren proposed openstack/openstacksdk master: Add support for additional volume backup options https://review.opendev.org/688353
09:28:30 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk stable/train: Consistent normalization of Machine objects in the cloud layer https://review.opendev.org/712295
10:32:51 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Fix microversion negotiation in some bare metal node call https://review.opendev.org/712336
10:32:59 dtantsur sshnaidm: this ^^^ is probably your issue
10:33:03 dtantsur testing appreciated
10:39:49 dtantsur (this approves that microversion negotiation is hard.. even I do it wrong all the time)
10:39:52 dtantsur * proves
11:05:07 dtantsur mordred: I have a feeling we're somehow running master tests on train Oo see the ironic job https://review.opendev.org/#/c/712295/1
11:05:46 dtantsur rpittau: do you have a follow-up for the 'retired' functional tests?
11:06:00 dtantsur we somehow end up failing them on train (because the feature is not there)
11:06:24 rpittau dtantsur: yes https://review.opendev.org/711958
11:06:48 rpittau mmm
11:06:57 dtantsur cool, +A
11:08:00 dtantsur rpittau: oh, sorry, there is an issue there, could you check?
11:08:05 rpittau sure
11:08:21 dtantsur you end up duplicating all tests because of inheritance
11:10:06 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Set min version to test node retirement https://review.opendev.org/711958
11:10:26 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Set min version to test node retirement https://review.opendev.org/711958
11:50:26 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Fix microversion negotiation in some bare metal node call https://review.opendev.org/712336
13:49:43 openstackgerrit Merged openstack/openstacksdk master: Set min version to test node retirement https://review.opendev.org/711958
13:51:05 dtantsur mordred: when you have a minute: https://review.opendev.org/#/c/712336/
14:15:36 mordred dtantsur: oy.
14:24:28 mordred dtantsur: microversion negotiation is hard
14:24:35 dtantsur it is indeed..
14:25:20 smcginnis It would be great if OSC supported microversions. :P
14:33:28 dtantsur first, we need to agree on the default behavior..
15:19:23 mordred smcginnis: it does support microversion
15:19:26 mordred microversions
15:24:02 mordred dtantsur: I agree we need to agree on the default behavior. I'd like to argue that osc's default behavior should match SDK's- which is that it should negotiate for the most recent microversion it can handle for a given command
15:24:58 mordred this is a little self-serving of course - since the long-term plan is to port osc on top of sdk - one would imagine that at that point osc's microversion behavior would be delegated to sdk anyway - so it would be good if porting to sdk didn't produce a behavior change
15:25:40 smcginnis mordred: I should have put <sarcasm/> tags on there. ;)
15:26:18 mordred smcginnis: :)
15:27:10 mordred that said - the current OSC behavior if you try something like compute_api_version: 2.latest is ridiculous
15:27:34 mordred but that's going to be because it just defers to novaclient and novaclient's behavior in that case is ridiculous
15:28:04 smcginnis I pushed back on that approach in cinder.
15:30:17 mordred well - the bad behavior here is that 2.latest is just an alias for "2.$whatever_the_highest_Version_hardcoded_into_novaclient_is" ... and is _not_ "2.please_negotiate_for_the_latest_available_version"
15:30:50 mordred so if you set 2.latest and then run opensatck server list against vexxhost, you get: clean_up ListServer: Version 2.81 is not supported by the API. Minimum is 2.1 and maximum is 2.60. (HTTP 406) (Request-ID: req-d368c068-4e37-448c-8e25-74e4aa0385a9)
15:30:58 mordred rather than just getting interactions at 2.60
15:48:08 mordred dtantsur: ooh. I think I just had an epiphany of how to support 2.latest in sdk safely
15:48:25 mordred WIP patch coming
15:52:38 dtantsur nice!
15:52:59 dtantsur I think in ironic OSC plugin we treat 1 like 1.latest and support it in the correct sense..
15:53:16 smcginnis Yeah, couldn't OSC do the negotiation to figure out the highest?
15:57:11 openstackgerrit Merged openstack/openstacksdk master: Fix microversion negotiation in some bare metal node call https://review.opendev.org/712336
16:02:27 mordred smcginnis: sort of - the problem is that if you just do straight latest then a new microversion can come and break you
16:02:37 mordred because there is additional processing of resources returned
16:03:27 mordred smcginnis: which is why what you _really_ want is "negotiate for the latest the client understands" (which is the power of microversions in the first place)
16:04:33 mordred in practice, if we start pro-actively adding support for a service's microversion as part of adding the new whatever to the server API
16:04:43 mordred this should have the result people are looking for and remain safe
18:33:57 yoctozepto mordred: may I get your attention on https://review.opendev.org/711492 ? it seems I "fixed" devstack enough to provide what sdk requires, yet it does not accept the 'example' key config
18:39:57 mordred yoctozepto: looking
18:48:28 mordred yoctozepto: https://zuul.opendev.org/t/openstack/build/d28bf0dd977942f4ac7b6331bce2ccd8/log/controller/logs/etc/openstack/clouds.yaml#23-24
18:48:33 mordred yoctozepto: that's not in the right place
18:48:47 mordred example should be a top-level config - a sibling of clouds
18:49:40 mordred yoctozepto: so it's not a property of the devstack-admin cloud
18:50:30 yoctozepto mordred: ack, that makes sense; just notice that 'functional' actually is and sdk docs claim that 'example' should be as well: https://opendev.org/openstack/openstacksdk/src/branch/master/doc/source/contributor/clouds.yaml
18:51:03 mordred one sec
18:51:14 yoctozepto mordred: feeling confused about the dichotomy
18:51:34 mordred yoctozepto: BWAHAHAHA. ok. yeah
18:51:50 mordred I think theres totally a bug here - let me propose a patch
18:52:08 mordred and ... maybe let's see if we can remove the need for a separate "example" image setting
18:52:20 yoctozepto mordred: I'd love that
19:05:24 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk stable/train: Fix microversion negotiation in some bare metal node call https://review.opendev.org/712536
19:05:56 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538
19:06:02 mordred yoctozepto: ^^
19:06:21 mordred yoctozepto: with that, you should be able to stop writing out the example config specially
19:06:44 mordred yoctozepto: if that all works, I'd like to change where we're writing the functional config since it's currently just flat wrong :)
19:06:59 mordred and thanks - that's a leftover mess from the merge
19:08:28 yoctozepto mordred: quickie - the patch I mentioned modifies devstack to use this config at all, I based it off the docs and got functional working
19:08:40 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538
19:08:46 yoctozepto mordred: you can go ahead and do it the best way you want
19:08:55 yoctozepto mordred: devstack won't break :-)
19:09:01 yoctozepto mordred: and I will adapt
19:09:04 mordred yoctozepto: :)
19:09:25 mordred yoctozepto: awesome - well, let's get it update so that the docs are right and so that we're using an exposed api inside of our own tests in sdk
19:09:50 mordred because we _do_ use get_extra_config in other places - so it's a real way to pass this information
19:10:25 mordred I don't know why we weren't using it in functional/base - nor why the examples docs were wrong even though the examples code WAS doing the right thing
19:10:26 yoctozepto mordred: ok, then just ditch the 'functional' difference
19:11:08 mordred yeah - we'll drive everything in the functional tests with the functional entry
19:11:26 mordred then we can fix the location of the functional entry later in the file as a followup
19:12:51 yoctozepto mordred: sure, let me know when you have your final change on sdk side and I'll base the devstack part accordingly
19:19:57 mordred yoctozepto: OH - duh
19:20:19 mordred yoctozepto: I just realized you're adding both functional AND example in that change
19:20:53 mordred yoctozepto: let me make my change the correct/simple version - no need to continue to work with the thing that doesn't exist
19:22:01 yoctozepto mordred: yeah, I tried to tell you that
19:22:18 yoctozepto mordred: also found breakage in your patch, commented
19:24:16 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538
19:24:54 mordred yoctozepto: thanks - yes you are right with your comment :) - and yes you did - I just didn't quite follow it in my brainhole
19:25:49 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538
19:25:57 mordred yoctozepto: I think that one should be good
19:28:50 yoctozepto mordred: no problem, one more comment
19:35:05 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538
19:35:12 mordred yoctozepto: good catch
19:44:10 yoctozepto mordred: thanks, now +1 :-)
19:47:00 mordred woot!
19:47:39 mordred Shrews: ^^ does that have any impact we should consider on nodepool

Earlier   Later