cilium

[v1.17] gh: e2e-upgrade: disable upgrade testing for config 12

#39137

Closed

The downgrade to v1.16 for this particular config has been broken for a few days, with no obvious culprit. Unblock CI until we understand the problem.

/test

Looking at https://github.com/cilium/cilium/actions/workflows/tests-e2e-upgrade.yaml?query=branch%3Av1.17, it's unclear whether this is caused by breakage in v1.17 or v1.16. Or a combination of both?

Needed to unblock #39128.

Is this the failure you're referring to? https://github.com/cilium/cilium/actions/runs/14628040109/job/41044267475#step:31:59 Can we file an issue so at least there's a reference for why we're not testing upgrades for this configuration?

I've noticed this configuration 12 seems to be more sensitive to cilium-health bootstrapping as we had a related problem on main recently (#39034), but we didn't get all the way to the bottom of why this specific configuration behaves differently than the others.

EDIT: I glanced through the v1.17 e2e-upgrade results and found three examples of the above failure, and they all occurred when deploying v1.16. Could be a regression on that branch, but broadly I'm fine with disabling this test if we think the risk of disabling the tests is relatively low and we don't have the time to dig into the failures at the moment.

Is this the failure you're referring to? https://github.com/cilium/cilium/actions/runs/14628040109/job/41044267475#step:31:59 Can we file an issue so at least there's a reference for why we're not testing upgrades for this configuration?

I've noticed this configuration 12 seems to be more sensitive to cilium-health bootstrapping as we had a related problem on main recently (#39034), but we didn't get all the way to the bottom of why this specific configuration behaves differently than the others.

Not the first time that this config has had such troubles ... if we can isolate a specific way to break only this config, I'd love to toggle some of the advanced wireguard options (node-to-node, strict-mode), and see what changes.

EDIT: I glanced through the v1.17 e2e-upgrade results and found three examples of the above failure, and they all occurred when deploying v1.16. Could be a regression on that branch, but broadly I'm fine with disabling this test if we think the risk of disabling the tests is relatively low and we don't have the time to dig into the failures at the moment.

ack I'll keep a closer look on whether the workflow has recovered now. For the PR that needed unblocking we ended up winning the re-run lottery, so no rush.

This pull request has been automatically marked as stale because it
has not had recent activity. It will be closed if no further activity
occurs. Thank you for your contributions.