Open lobkovilya opened 10 months ago
Here is a try of implementing the last one https://github.com/kumahq/kuma/pull/9034 However, it's easy to get into KDS race condition. It is similar to a problem where you try to apply a Mesh-scoped resource, but you don't have Mesh yet.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
Problem
A user should export meshes to global CP before connecting a non-federated zone to it. If a user made a mistake and didn't export all meshes, then the initial KDS request is going to remove unexported meshes in the zone.
Solution
The first idea was to not delete resources in
Sync
if they're originated locally (kuma.io/orign: zone
or origin is not set). But in this case, renaming of the policies on global (by adding a hash suffix) doesn't work and old policies namedroute-all-${mesh}
are not replaced.Another idea was to not delete resources in
Sync
if they don't haveZoneToGlobalFlag
(i.e. Mesh, Secrets) and they're originated locally. In this case, even though we're preserving unexported meshes in the zone, we're still losing policies of these meshes.During migration zone CP can't certainly determine if the policy has to be deleted or sent to the global CP by looking at the policy only. Probably the solution we're looking for should contain checking the mesh of each policy, and if the mesh doesn't have
kuma.io/origin: global
label then we're dealing with a user mistake and the policy needs to be preserved.