Basically, we try the update as provided. If it fails, then we retry it removing the "tier" from the object. This allows us to call applyPatch on an object without the tier prefix, which passes the name validation.
Once it passes the applyPatch name validation, it continues on to PrepareForUpdate, at which point we need to re-canonicalize the objects to include the tier prefix on them for storage...
I am not sure this is a viable solution - we need to think about what happens if there actually are policies in different tiers and someone tries to send a PATCH. I think it might just be OK, because in the second case you would need to specify the tier name (it's only for default that this is really a problem?)
At a minimum, for this change to go in we'd want to also:
Only apply this logic for policies in the default tier
Only apply this logic if we get the precise error back that we expect in the mismatched tier case.
Related issues/PRs
Todos
[ ] Tests
[ ] Documentation
[ ] Release note
Release Note
TBD
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one docs-* label.
docs-pr-required: This change requires a change to the documentation that has not been completed yet.
docs-completed: This change has all necessary documentation completed.
docs-not-required: This change has no user-facing impact and requires no docs.
Every PR needs one release-note-* label.
release-note-required: This PR has user-facing changes. Most PRs should have this label.
release-note-not-required: This PR has no user-facing changes.
Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.
Description
This is one attempt at fixing https://github.com/projectcalico/calico/issues/9437
Basically, we try the update as provided. If it fails, then we retry it removing the "tier" from the object. This allows us to call applyPatch on an object without the tier prefix, which passes the name validation.
Once it passes the applyPatch name validation, it continues on to PrepareForUpdate, at which point we need to re-canonicalize the objects to include the tier prefix on them for storage...
I am not sure this is a viable solution - we need to think about what happens if there actually are policies in different tiers and someone tries to send a PATCH. I think it might just be OK, because in the second case you would need to specify the tier name (it's only for default that this is really a problem?)
At a minimum, for this change to go in we'd want to also:
Related issues/PRs
Todos
Release Note
Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one
docs-*label.docs-pr-required: This change requires a change to the documentation that has not been completed yet.docs-completed: This change has all necessary documentation completed.docs-not-required: This change has no user-facing impact and requires no docs.Every PR needs one
release-note-*label.release-note-required: This PR has user-facing changes. Most PRs should have this label.release-note-not-required: This PR has no user-facing changes.Other optional labels:
cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.