v1.14 Backports 2024-02-29 #31048
Merged
v1.14 Backports 2024-02-29 #31048
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
YutaroHayakawa
added
kind/backports
|
/test-backport-1.14 |
aanm
approved these changes
Feb 29, 2024
|
Conformance Kind Envoy DaemonSet, Conformance Multi Pool IPAM: Timeout while initializing Cilium |
|
Cilium IPsec upgrade: #29987 |
qmonnet
approved these changes
Feb 29, 2024
[ upstream commit 9620979 ] [ backporter's note: Had a following conflict ++<<<<<<< HEAD ++======= + // If the endpoint is in an 'init' state we need to remove this label + // regardless of the "sourceFilter". Otherwise, we face risk of leaving the + // endpoint with the reserved:init state forever. + // We will perform the replacement only if: + // - there are new identity labels being added; + // - the sourceFilter is not any; If it is "any" then it was already + // replaced by the previous replaceIdentityLabels call. + // - the new identity labels don't contain the reserved:init label + // - the endpoint is in this init state. + if len(identityLabels) != 0 && + sourceFilter != labels.LabelSourceAny && + !identityLabels.Has(labels.NewLabel(labels.IDNameInit, "", labels.LabelSourceReserved)) && + e.IsInit() { + + idLabls := e.OpLabels.IdentityLabels() + delete(idLabls, labels.IDNameInit) + rev = e.replaceIdentityLabels(labels.LabelSourceAny, idLabls) + } + ++>>>>>>> 4ec84be6b1 (pkg/endpoint: remove reserved:init from endpoints) Took a 4ec84be6b1's one. ] Previously, a bug introduced in e43b759 caused the 'reserved:init' label to persist even after an endpoint received its security identity labels. This resulted in endpoints being unable to send or receive any network traffic. This fix ensures that the 'reserved:init' label is properly removed once initialization is complete. Fixes: e43b759 ("pkg/endpoint: keep endpoint labels for their original sources") Signed-off-by: André Martins <andre@cilium.io> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
[ upstream commit 6fee46f ] [ backporter's note: - e2e upgrade test doesn't exist in this branch. Removed it. - Minor conflict in tests-clustermesh-upgrade.yaml ++<<<<<<< HEAD + if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then + SHA="${{ inputs.SHA }}" + else + SHA="${{ github.sha }}" + fi ++======= + CILIUM_DOWNGRADE_VERSION=$(contrib/scripts/print-downgrade-version.sh stable) + echo "downgrade_version=${CILIUM_DOWNGRADE_VERSION}" >> $GITHUB_OUTPUT ++>>>>>>> 8c3b175f5d (ci/ipsec: Fix downgrade version retrieval) ] Figuring out the right "previous patch release version number" to downgrade to in print-downgrade-version.sh turns out to be more complex than expected [0][1][2][3]. This commit is an attempt to 1) fix issues with the current script and 2) overall make the script clearer, so we can avoid repeating these mistakes. As for the fixes, there are two things that are not correct with the current version. First, we're trying to validate the existence of the tag to downgrade to, in case the script runs on top of a release preparation commit for which file VERSION has been updated to a value that does not yet contains a corresponding tag. This part of the script is actually OK, but not the way we call it in the IPsec workflow: we use "fetch-tags: true" but "fetch-depth: 0" (the default), and the two are not compatible, a shallow clone results in no tags being fetched. To address this, we retrieve the tag differently: instead of relying on "fetch-tags" from the workflow, we call "git fetch" from the script itself, provided the preconditions are met (we only run it from a Git repository, if the "origin" remote is defined). If the tag exists, either locally or remotely, then we can use it. Otherwise, the script considers that it runs from a release preparation Pull Request, and decrements the patch release number. The second issue is that we would return no value from the script if the patch release is zero. This is to avoid any attempt to find a previous patch release when working on a development branch. However, this logics is incorrect (it comes from a previous version of the script where we would always decrement the patch number). After the first release of a new minor version, it's fine to have a patch number at 0. What we should check instead is whether the version ends with "-dev". This commit brings additional changes for clarity: more comments, and a better separation between the "get latest patch release" and "get previous stable branch" cases, moving the relevant code to independent functions, plus better argument handling. We also edit the IPsec workflow to add some logs about the version retrieved. The logs should also display the script's error messages, if any, that are printed to stderr. Sample output from the script: VERSION Tag exists Prevous minor Previous patch release 1.14.3 Y v1.13 v1.14.3 1.14.1 Y v1.13 v1.14.1 1.14.0 Y v1.13 v1.14.0 1.14.1-dev N v1.13 <error> 1.15.0-dev N v1.14 <error> 1.13.90 N v1.12 v1.13.89 <- decremented 2.0.0 N <error> <error> 2.0.1 N <error> v2.0.0 <- decremented 2.1.1 N v2.0 v2.1.0 <- decremented [0] 56dfec2 ("contrib/scripts: Support patch releases in print-downgrade-version.sh") [1] 4d7902f ("contrib/scripts: Remove special handling for patch release number 90") [2] 5581963 ("ci/ipsec: Fix version retrieval for downgrades to closest patch release") [3] 3803f53 ("ci/ipsec: Fix downgrade version for release preparation commits") Fixes: 3803f53 ("ci/ipsec: Fix downgrade version for release preparation commits") Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
YutaroHayakawa
force-pushed
the
pr/v1.14-backport-2024-02-29-01-03
branch
from
9d74bcb
to
e12c8ce
Compare
|
/test-backport-1.14 |
ldelossa
approved these changes
Feb 29, 2024
christarazi
approved these changes
Feb 29, 2024
maintainer-s-little-helper
bot
added
the
ready-to-merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Once this PR is merged, a GitHub action will update the labels of these PRs: