#3418 [Core feature] Matchable resource updates should show diffs/force confirm on overrides Issue created by katrogan Motivation: Why do you think this is important? When updating project or workflow based matchable resources using flytectl, users can run into a scenario where an existing override exists and their call to update completely overwrites it. This isn't always intentional so having a merging strategy or some kind of confirmation can help reduce churn in unintentional updates For example, existing cluster resource controller attrs:

domain: development
project: flytesnacks
attributes:
  foo: "bar"

which are then updated with

domain: development
project: flytesnacks
attributes:
  buzz: "lightyear"

completely removes the existing foo template value (which means the actual rendering falls back to the application default.) Users may intend for their behavior to be a merge but be unaware an existing override exists. We should reduce the potential for unintended overrides. Goal: What should the final outcome look like, ideally? It should be difficult to unintentionally overwrite matchable resources. Describe alternatives you've considered The current system is error prone. The below proposals are just some suggestions for making sure we don't introduce accidental overwrites. Propose: Link/Inline OR Additional context We could • have flytectl first do a get before writing an update and showing a lightweight, terraform plan like preview of the applied changes and require user confirmation • Introduce a dry run flag to show anticipated changes • Use a kubernetes-like versioning scheme for making sure only the latest version of a resource is applied in update calls (you can't overwrite with a stale version) • this would be a wider-sweeping and more complicated change for a behavior that is infrequently exercised Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte