[release/1.7] Fix initial sync race when registering NRI plugins #11326
Conversation
dosubot
bot
added
area/nri
klihub
force-pushed
the
fixes/1.7/nri-plugin-sync
branch
2 times, most recently
from
2d08d83 to
83f7b51
Compare
|
/test pull-containerd-node-e2e-1-7 |
Signed-off-by: Krisztian Litkey <[email protected]>
Block the synchronization of registering NRI plugins during CRI events to avoid the plugin ending up in an inconsistent starting state after initial sync (missing pods, containers or missed events for some pods or containers). Signed-off-by: Krisztian Litkey <[email protected]>
klihub
force-pushed
the
fixes/1.7/nri-plugin-sync
branch
from
83f7b51 to
11af051
Compare
|
🤞🏼 the ttrpc update has the magic fix for the almalinux 8 test failure. Is that optimistic wishing? containerd 2.0 branch is testing almalinux 8 and this fix was successful there. |
Yeah, I'm not sure if it's a flake or not. There are PRs against 1.7 that pass all tests (#11346) and there are ones that failed on almalinux8 (#11358). So unless someone has definite proof that tests are now flakey on almalinux8 for a known reason, I'd say let's play safe, assume that this PR breaks something, and keep it out from the imminent 1.7 release. I'll need to then dig in and try to figure out what goes on, so it could get into 1.7.27... |
dmcgowan
changed the title
Update NRI deps to v0.8.0 and fix racy initial NRI plugin synchronization wrt. event processing by blocking plugin synchronization altogether during CRI event processing.
Notes: this PR does not pull in the latest tagged NRI version (v0.9.0) to keep the blast radius smaller. We can pull in NRI v0.9.0 if that is preferred. That would also pull in support for NRI WASM plugins and the related wazero and go-plugin dependency bits.