Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-07-27
10:13:37 bauzas kashyap: honestly, my thought is just about operators looking at our notes
10:13:40 bauzas I know some of them
10:13:50 kashyap bauzas: Yeah, I get that
10:13:52 bauzas in general, they look at two sections
10:13:54 kashyap bauzas: How about "other", then?
10:14:06 bauzas kashyap: if you want
10:14:18 bauzas my only concern was about the 'upgrade' section
10:14:24 kashyap bauzas: Just vote - you and Sean :)
10:14:33 bauzas as I was saying, operators look at two sections
10:14:34 kashyap "feature" or "other"
10:14:48 kashyap I'll respin right away (inncluding the backports)
10:15:18 bauzas they look at the prelude section (for knowing what we have) and at the upgrade section (to know what they need to verify)
10:15:41 bauzas here, they don't need to verify anything
10:15:45 bauzas hence my concern
10:16:00 bauzas kashyap: about 'feature' or 'other', meh.
10:17:55 kashyap bauzas: Sure, I'll go w/ 'feature'
10:18:03 bauzas thanks
10:18:22 bauzas appreciated
10:20:23 opendevreview Kashyap Chamarthy proposed openstack/nova master: Add a workaround to skip hypervisor version check on LM https://review.opendev.org/c/openstack/nova/+/851034
10:20:51 opendevreview Kashyap Chamarthy proposed openstack/nova stable/yoga: Add a workaround to skip hypervisor version check on LM https://review.opendev.org/c/openstack/nova/+/851202
10:21:29 opendevreview Kashyap Chamarthy proposed openstack/nova stable/xena: Add a workaround to skip hypervisor version check on LM https://review.opendev.org/c/openstack/nova/+/851205
10:31:29 kashyap bauzas: --^
10:31:42 bauzas kashyap: you're late
10:31:46 kashyap Hehe
10:31:54 kashyap Thank you!
10:32:32 kashyap bauzas: Can you also ACK the backports, then, please?
10:32:43 bauzas I can
10:34:16 kashyap Thx
10:34:35 kashyap sean-k-mooney[m]: Unrelated - I see this is still active, can you pls ACK this too: "[nova/libvirt] Support for checking and enabling SMM when needed
10:34:38 kashyap "
10:34:39 kashyap https://review.opendev.org/c/openstack/nova/+/849610
10:35:02 kashyap (Cc: gibi)
10:36:42 opendevreview Kashyap Chamarthy proposed openstack/nova stable/wallaby: Add a workaround to skip hypervisor version check on LM https://review.opendev.org/c/openstack/nova/+/851206
10:40:28 sean-k-mooney kashyap: i wasnt going to review teh wallaby backport until the xena one had merged
10:40:35 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/849676
10:40:36 kashyap Sure
10:40:45 kashyap But it's the same thing
10:41:09 sean-k-mooney yes but it cant merge until that one does so i review them in order
10:41:12 kashyap Sigh, also this stable/yoga backport is not merged yet - https://review.opendev.org/c/openstack/nova/+/845045 (libvirt: Add a workaround to skip compareCPU() on destination
10:41:15 kashyap )
10:41:23 kashyap sean-k-mooney: Oh, sure
11:44:54 opendevreview Merged openstack/nova master: Allow unshelve to a specific host (Compute API part) https://review.opendev.org/c/openstack/nova/+/831507
11:45:01 opendevreview Merged openstack/nova master: Allow unshelve to a specific host (REST API part) https://review.opendev.org/c/openstack/nova/+/845897
11:45:06 gibi \o/
11:46:51 sean-k-mooney stephenfin: gibi how do we want to proceed with the mock change?
11:46:58 gibi sean-k-mooney: good question
11:47:13 sean-k-mooney im kind of sad that we chose to delay it last cycle
11:47:16 sean-k-mooney to drop 3.6
11:47:18 gibi sean-k-mooney: I'm not sure I will have enough time today to try to fix the duplicate mock issue
11:47:27 sean-k-mooney and now we added 3.10 which is causing other issues
11:47:40 gibi I don't know if stephenfin looked at it yet or not
11:49:19 gibi I can be convinced to let it land and fix the 310 issue separately I just affraid that we will forget about it and only realize it again when we want to make the py310 job votinh
11:49:23 gibi g
11:50:18 sean-k-mooney ya thats a valid concen
11:50:32 sean-k-mooney the 3.10 fixes shoudl be a seperate patch in my opipion
11:50:41 sean-k-mooney it would be nice ot have it in the seriese
11:50:42 gibi I agree with that
11:50:49 sean-k-mooney but not sure how much work it is
11:51:02 sean-k-mooney im also not partically happy with the decision they made in 3.10
11:51:03 gibi me neither but I feel like it is not a oneliner
11:51:31 sean-k-mooney double mocking is perhaps ineffenct but i think it should be allowed
11:51:48 sean-k-mooney so im sad they made that breakign change
11:52:32 gibi lets wait for stephenfin to chime in. Also I can try to look into it tomorrow to see how big is the issue
11:52:36 gibi then we can reconsider
11:52:48 sean-k-mooney we might need to add a helper funciton that check if its mocked and only create a new mock if not
11:52:59 gibi I would go and remove the duplicates if possible
11:53:08 gibi but I don't know how hard that will be
11:53:17 sean-k-mooney yes if we can do that once
11:53:25 sean-k-mooney then we will never hit this again because it will fail
11:53:35 gibi the helper feels like a coverup
11:54:00 sean-k-mooney im just worried about loading the context of is this mocked
11:54:27 sean-k-mooney again with the new behaivor it shoudl be obvious i guess because it will fail
11:54:34 gibi yeah
11:56:48 sean-k-mooney i just hope this does not cause shared global state
11:57:11 sean-k-mooney the fixture should be set up for every test
11:57:37 sean-k-mooney but we likely will have to replace part of them in the test where its double mocking
11:58:02 sean-k-mooney as i feel like we double mock somethimes when the fixture does not provide exactly what we want
11:58:09 sean-k-mooney i know i have done that at least once
11:58:32 gibi yes, I think that is the "normal" case when we double mock. I did that before
11:58:42 gibi so in this case the fixture should expose the mock
11:58:54 gibi so the test case can use it instead of remocking it
11:59:18 sean-k-mooney well we can jsut create a new mock object and assign it
11:59:27 sean-k-mooney instaed of having it patch it again
11:59:40 gibi we cannot create the new Mock as autospec will fail
11:59:54 gibi as it will try to spec what is already mocked
12:00:08 sean-k-mooney we can with mock.Mock()
12:00:13 gibi hm
12:00:14 sean-k-mooney we dont tend to use autospec much
12:00:29 sean-k-mooney we do in somecases but i rarely do
12:01:14 gibi A().foo = mock.Mock() is a monkeypatch that is not reverted automatically so that is a bad pattern
12:01:43 gibi also I think there is automatic autospecing in the mock lib (obviously not for mock.Mock() but for mock.patch decorator)
12:02:09 sean-k-mooney i dont think there is
12:02:14 sean-k-mooney or at least
12:02:21 sean-k-mooney its behavior shoudl be the same as the standard lib
12:02:28 sean-k-mooney so if there is it shoudl be in both
12:02:48 sean-k-mooney gibi: in the A().foo = mock.Mock()
12:03:08 sean-k-mooney we shoudl not need to revert that automaticlly if A is a mock already
12:03:52 gibi ahh, yeah, I ment there is automatic autospec in both lib and stdlib
12:04:56 gibi sean-k-mooney: yeah, if A().foo is already a mocked then that mock's patcher.stop() will revert the change. But the caller doing the A().foo = mock.Mock() does not know if foo is a Mock. So we establish a dangerous pattern
12:05:37 gibi if that pattern is used to other than a mocked field the we will leak global state between tests

Earlier   Later