| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 15:08:48 | bauzas | sean-k-mooney: well, we raise_exc=False | |
| 15:10:37 | gibi | bauzas: now I read back, It is OK to me what you and sean-k-mooney come up with | |
| 15:12:04 | sean-k-mooney | bauzas: so we check if the multi provide net extension exist here https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#3524 | |
| 15:12:33 | sean-k-mooney | but we shoudl be checking if the segment extions exists | |
| 15:14:23 | bauzas | this sounds a reasonable ask | |
| 15:14:59 | sean-k-mooney | we can cache it the same way we do with the other check so we only do it once. | |
| 15:15:03 | bauzas | sean-k-mooney: but my question remains open, do we get an empty list for a network that doesn't do routed segments or whatever else ? | |
| 15:16:32 | sean-k-mooney | the api ref does not say but i would expect the list endpoint which we are calling to return an empty list | |
| 15:16:37 | sean-k-mooney | i can check there unit tests | |
| 15:17:13 | bauzas | sean-k-mooney: thanks | |
| 15:18:14 | stephenfin | bauzas, lyarwood, gibi, (anyone else): This is not high priority work, but I have an ass-load of OSC patches that would benefit from some nova devs' eyes | |
| 15:18:15 | stephenfin | https://review.opendev.org/q/project:openstack/python-openstackclient+status:open+file:compute+owner:stephenfin%2540redhat.com | |
| 15:18:43 | gibi | stephenfin: now queued them for review | |
| 15:19:08 | stephenfin | I've been skimming through novaclient commands, mapping them to OSC equivalents, and figuring out what's missing. I'm getting very close to feature parity with those and know where the remaining gaps are | |
| 15:19:12 | stephenfin | gibi: \o/ thanks! | |
| 15:19:21 | bauzas | stephenfin: opened the link but later, I'm sorry | |
| 15:19:42 | stephenfin | Later is good. This is low priority. I just want it to move _eventually_ :) | |
| 15:19:55 | bauzas | stephenfin: ping me tomorrow morning then | |
| 15:20:11 | lyarwood | stephenfin: ack open, I'll start looking through them now | |
| 15:23:03 | gibi | stephenfin: there is a probable mitigation for the long standing bug 1823251 https://review.opendev.org/c/openstack/nova/+/765300 | |
| 15:23:03 | openstack | bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] https://launchpad.net/bugs/1823251 | |
| 15:23:28 | stephenfin | gibi: looking | |
| 15:23:35 | gibi | so far I was not able to reproduce the bug with this patch in 10 CI runs | |
| 15:25:09 | bauzas | sean-k-mooney: I mean, my concern is to know whether we can know that if we get an empty list of aggregates, it's either fine or not | |
| 15:27:24 | sean-k-mooney | https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8ddf65bd46/neutron/tests/unit/extensions/test_segment.py#L341-L351 | |
| 15:27:42 | sean-k-mooney | so it will be a list of segments i think but it will be empty still checking | |
| 15:31:44 | sean-k-mooney | gibi i hit that bug too | |
| 15:32:21 | gibi | sean-k-mooney: all of us hit that during the past one and a half year, we turned that test off during FF many times in the past to make patches land | |
| 15:32:40 | gibi | it seems like an unsolvable thing | |
| 15:32:42 | sean-k-mooney | oh i mean i have seen it in the last week | |
| 15:32:44 | gibi | at least to me | |
| 15:33:02 | bauzas | sean-k-mooney: well, ok, so no way to distinct in between networks not using routed segments vs. networks using routed segments but with no aggregate for this segment | |
| 15:33:03 | gibi | yeah, recently I seen it almost every day, hence my new atempt to sovle it | |
| 15:33:23 | sean-k-mooney | bauzas:right but the later case should never happen | |
| 15:33:58 | sean-k-mooney | bauzas: neutron always creates the aggreates if the segments service plugin is loaded | |
| 15:34:18 | sean-k-mooney | which is what provides routed network support in neutron | |
| 15:35:03 | bauzas | sean-k-mooney: ok, so, just checking the extension is enough | |
| 15:35:20 | bauzas | and getting no aggregates is totally fine | |
| 15:35:33 | sean-k-mooney | getting no segments is fine | |
| 15:35:53 | sean-k-mooney | if we get segment but done get aggreates for those segment that a neutorn issue | |
| 15:36:05 | gibi | ^^ +1 | |
| 15:36:05 | bauzas | ok, then I'll distinct this | |
| 15:36:06 | sean-k-mooney | it means neutron could not create them for some reason | |
| 15:36:19 | bauzas | in scheduler.utils | |
| 15:36:36 | bauzas | okay, I should be able to upload a new rev in 10 mins | |
| 15:36:45 | bauzas | still a WIP tho | |
| 15:36:45 | sean-k-mooney | cool | |
| 15:37:05 | sean-k-mooney | by did i see correctly that you are adding the network request to the request spec | |
| 15:37:32 | sean-k-mooney | i might have a use for that in for one of my specs | |
| 15:38:14 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/765901/1/specs/wallaby/approved/port-scoped-sriov-numa-affinity.rst#75 | |
| 15:38:54 | sean-k-mooney | i was planning to add a prefilter but realised i did not have the requested networks in the prefilter | |
| 15:39:16 | sean-k-mooney | so i was going to move it eairler but i think i can just build on your change instead | |
| 15:39:32 | sean-k-mooney | bauzas: can you review and provide input on that in particalar | |
| 15:40:42 | bauzas | sean-k-mooney: okay, will look | |
| 15:42:03 | sean-k-mooney | there is an clean way to do it with out a prefiler but i dont want to break the patern if i dont have to | |
| 15:53:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add requested_networks field to RequestSpec object https://review.opendev.org/c/openstack/nova/+/749977 | |
| 15:53:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Add a routed networks scheduler pre-filter https://review.opendev.org/c/openstack/nova/+/749068 | |
| 16:30:09 | melwitt | LarsErikP: I can take care of the merge conflict for the ussuri backport, no worry | |
| 16:30:35 | melwitt | for the victoria one, we are currently stuck behind a known gate failure, I posted a note on the review | |
| 17:06:03 | stephenfin | lyarwood: should I even bother exposing this if it's really internal only? https://review.opendev.org/c/openstack/python-openstackclient/+/765366 | |
| 17:07:17 | lyarwood | stephenfin: yeah we could just block it in the cli | |
| 17:07:31 | lyarwood | stephenfin: but I'm assuming that will create future up and/or downstream bugs | |
| 17:07:40 | lyarwood | stephenfin: but they always have the API | |
| 17:08:15 | stephenfin | that's what I'm thinking. I'm not converting e.g. the 'nova reset-network' command | |
| 17:08:16 | lyarwood | stephenfin: that said the recently landed update stuff is actually useful outside of swap volume | |
| 17:08:46 | lyarwood | stephenfin: so you would just be blocking the swap volume stuff and allowing the volume update flow | |
| 17:09:18 | lyarwood | stephenfin: and FWIW this is why I wanted the swap volume flow fork lifted out from this API *before* we landed the volume update stuff | |
| 17:09:31 | stephenfin | so I'd drop the dst_volume argument and simply use src_volume for both | |
| 17:09:39 | lyarwood | yeah | |
| 17:09:43 | stephenfin | I can do that | |
| 17:26:30 | melwitt | stephenfin: while you're here, do you think you might be able to give this patch to use unittest.mock instead of third party mock a refresh from merge conflicts? https://review.opendev.org/c/openstack/nova/+/714676 prometheanfire was asking yesterday if we'd made progress on support for mock 4.0.2 https://review.opendev.org/765680 | |
| 17:26:53 | melwitt | *while you're here, I wanted to ask | |
| 18:57:35 | stephenfin | melwitt: Sorry, missed that. I'd deprioritized that because I couldn't figure out what the gain was. mock (the pypi package) is a rolling backport of upstream changes and as such, any bugs it introduces are things we're going to have to fix when we reach that future Python version anyway | |
| 18:58:12 | sean-k-mooney | stephenfin: not always | |
| 18:58:14 | stephenfin | so sticking with mock and simply getting it working with 4.0 seemed a wiser course of action, tbh | |
| 18:58:17 | melwitt | oh, hm | |
| 18:58:23 | sean-k-mooney | we have nit bugs in there backported implemation | |
| 18:58:29 | sean-k-mooney | that are not there in the native one | |
| 18:59:01 | stephenfin | I don't think so, at least not from reading upstream bug reports | |
| 18:59:27 | stephenfin | any bugs are also present in unittest.mock on the either the latest Python or Python master, I don't recall which | |
| 18:59:33 | melwitt | stephenfin: I see, ok, I can try that approach then. I didn't realize why the conversion patch wasn't being worked | |
| 18:59:41 | sean-k-mooney | our inablity to use one of the mock decortors is due to mock the lib vs unittest.mock | |
| 19:00:12 | stephenfin | sean-k-mooney: my understanding of that was that it was also an issue in the Python 3.9 unittest.mock implementation | |
| 19:00:19 | sean-k-mooney | i think its teh use of assert raises as a context manager actully | |
| 19:00:38 | stephenfin | I can root out the bug report in the morning (dinner time here) | |
| 19:01:27 | stephenfin | melwitt: I think that might be a wiser approach, but I'm not the only one with a say here. It just seems foolish to have to work around bugs with e.g. unittest.mock on Python 3.6 when mock 3.x+ doesn't have them | |
| 19:03:12 | melwitt | stephenfin: no I think what you're saying makes sense, I think that would be a simpler way to address this | |
| 19:03:41 | sean-k-mooney | stephenfin: https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaises | |
| 19:03:45 | melwitt | I can put that together | |
| 19:03:53 | sean-k-mooney | with self.assertRaises(SomeException) as cm: | |
| 19:03:55 | sean-k-mooney | do_something() | |
| 19:04:03 | sean-k-mooney | stephenfin: that does not work with mock the lib | |
| 19:04:13 | sean-k-mooney | or at least it did not work in the past | |
| 19:05:28 | sean-k-mooney | perhaps its actully caused by soemthing else but that is what we belived it was blocking that form working in nova the last time we investigated | |
| 21:57:13 | JamesBenson | Hi all, I've modified my nova.conf with `cpu_mode = host-model` in a mixed CPU environment, but not all of my CPU flags passed through. What else am I missing? | |
| 23:40:18 | openstackgerrit | melanie witt proposed openstack/nova stable/victoria: WIP [stable-only] Target cell for min bw migration service lookup https://review.opendev.org/c/openstack/nova/+/766364 | |
| 23:42:36 | sean-k-mooney | JamesBenson: host model will not pass all the flags | |
| 23:43:27 | sean-k-mooney | JamesBenson: some cpu flags are not virtualisable but the real reason is host model chose the clost model to you actual cpu listed in qemus/libvirts cpu model xml file | |
| 23:44:06 | sean-k-mooney | those models are ment to represent the common set of flag commen to a specific generation of a cpu not the specific sku | |
| 23:44:31 | sean-k-mooney | so if you cpu has feature that are not avaiable on other cpus in the same generation those feature flags likely wont be present | |