Summary
Switching a cluster atomically between two profiles that define the same Helm release, but possibly different versions or values, should always have upgrade semantics rather than delete/install semantics regardless of stopMatchingBehaviour.
Problem statement
Suppose two cluster profiles A and B define the same Helm release, but with different versions or config.
Also suppose a cluster initially has labels that match A but not B, and then those labels are atomically updated so that the cluster now matches B and not A. The cluster never matches A and B simultaneously, but always matches one or the other.
In this case, the Helm release should never be deleted - only upgraded to the new version specified in profile B.
At the moment, this cannot be guaranteed without setting stopMatchingBehaviour=LeavePolicies, but this has the unwanted side effect that if profile A defines a Helm release that is no longer present in profile B, that release is never deleted.
Possible solution
If changing the labels on a cluster somehow triggered a refresh of the set of matching profiles and their releases for that cluster before any action is taken for any of them, then because the profile switch is atomic that would be sufficient for profile A to see that profile B is taking over.
I don't know the internals well enough to know if that is at all practical.
Slack thread
https://projectsveltos.slack.com/archives/C046P825BBL/p1778344079375349
Summary
Switching a cluster atomically between two profiles that define the same Helm release, but possibly different versions or values, should always have upgrade semantics rather than delete/install semantics regardless of
stopMatchingBehaviour.Problem statement
Suppose two cluster profiles A and B define the same Helm release, but with different versions or config.
Also suppose a cluster initially has labels that match A but not B, and then those labels are atomically updated so that the cluster now matches B and not A. The cluster never matches A and B simultaneously, but always matches one or the other.
In this case, the Helm release should never be deleted - only upgraded to the new version specified in profile B.
At the moment, this cannot be guaranteed without setting
stopMatchingBehaviour=LeavePolicies, but this has the unwanted side effect that if profile A defines a Helm release that is no longer present in profile B, that release is never deleted.Possible solution
If changing the labels on a cluster somehow triggered a refresh of the set of matching profiles and their releases for that cluster before any action is taken for any of them, then because the profile switch is atomic that would be sufficient for profile A to see that profile B is taking over.
I don't know the internals well enough to know if that is at all practical.
Slack thread
https://projectsveltos.slack.com/archives/C046P825BBL/p1778344079375349