We have the following yaml, which we use to create a new Keeper.

apiVersion: secret.grafana.app/v0alpha1
kind: Keeper
metadata:
  name: aws-xyz
spec:
  title: AWS XYZ value
  aws:
    accessKeyId: 
      valueFromEnv: ACCESS_KEY_ID_XYZ
    secretAccessKey:
      valueFromEnv: SECRET_ACCESS_KEY_XYZ

If we try to update this keeper, by changing it from aws to gcp for example:

apiVersion: secret.grafana.app/v0alpha1
kind: Keeper
metadata:
  name: aws-xyz
spec:
  title: AWS XYZ value
  gcp:
    projectId: project-id 
    credentialsFile: /path/to/file.json

This would fail. By default Kubernetes will try to merge fields on an UPDATE, which means the final spec would both have aws and gcp.

And that's the main change of this PR, which alters the strategy used when patching (updating) Keepers. Instead of merging, we will replace the whole spec.

There's a trade-off. While we gain flexibility by being able to completely change all fields of the spec, we aren't able to issue partial updates (patches) anymore.

If after creating the initial keeper, we tried to update its title:

apiVersion: secret.grafana.app/v0alpha1
kind: Keeper
metadata:
  name: aws-xyz
spec:
  title: My New Title

This would not work, because the validation would be missing a keeper configuration, since that's replace.

While before the change, it would use the aws field from the old object, and the title from the new, merging them.

I think that for now keeping the updates working as a PUT verb rather than PATCH is easier to reason about, but we can discuss it if needed.

Reference material I used:

• https://github.com/kubernetes/kube-openapi/blob/2c72e554b1e7755b5fbee01cc910063070d5b4ec/pkg/generators/extension.go#L48
• https://github.com/kubernetes/kube-openapi/blob/release-1.22/pkg/generators/openapi_test.go#L83
• https://github.com/kubernetes/kube-openapi/blob/release-1.22/pkg/idl/doc.go
• https://github.com/kubernetes/community/blob/6690abcd6b833f46550f5eaba2ec17a9e39b35c4/contributors/devel/sig-api-machinery/strategic-merge-patch.md#basic-patch-format