gatekeeper icon indicating copy to clipboard operation
gatekeeper copied to clipboard

Allow syncing all possible resource versions

Open FooBarWidget opened this issue 3 years ago • 11 comments

Describe the solution you'd like The replicating data feature requires explicitly specifying resource versions. I'd like to be able to sync all versions of a resource, without having to specify explicit versions. This way, when I upgrade my Kubernetes clusters (which may introduce new resource versions), I don't have to update my Gatekeeper config to include new resource versions.

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: gatekeeper-system
spec:
  sync:
    syncOnly:
      - group: networking.k8s.io
        kind: Ingress
        version: v1   # <--- please make this optional, or allow "*"
      - group: extensions
        kind: Ingress
        version: v1beta1

Environment:

  • Gatekeeper version: commit 07e2fd0 (part of Google Cloud Policy Controller 1.9.1)

  • Kubernetes version: (use kubectl version):

    Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:34:20Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"darwin/amd64"}
    Server Version: version.Info{Major:"1", Minor:"19+", GitVersion:"v1.19.14-gke.1900", GitCommit:"abc4e63ae76afef74b341d2dba1892471781604f", GitTreeState:"clean", BuildDate:"2021-09-07T09:21:04Z", GoVersion:"go1.15.15b5", Compiler:"gc", Platform:"linux/amd64"}
    

FooBarWidget avatar Nov 15 '21 14:11 FooBarWidget

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jul 23 '22 03:07 stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Oct 11 '22 06:10 stale[bot]

/reopen

ctml91 avatar Oct 25 '22 18:10 ctml91

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Dec 26 '22 03:12 stale[bot]

active

ctml91 avatar Dec 26 '22 04:12 ctml91

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Feb 24 '23 07:02 stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Apr 26 '23 13:04 stale[bot]

@anlandu @julianKatz please make sure the SyncSet design addresses this issue.

ritazh avatar Apr 26 '23 14:04 ritazh

Hey @FooBarWidget!

Thanks for this feedback. We're designing a feature that involves referential data sync configuration (like the Config resource's spec.sync.syncOnly field you mention), and wanted to check in with you on the friction you documented in this issue.

In particular, you mention how you are interested in having sync config that is durable across upgrades. I.e., if a version of a given GroupKind is added or removed, you'd prefer not to take the additional manual step of updating the Config. The wildcard (*) is solely a way of achieving that outcome.

Does that accurately portray your viewpoint?

julianKatz avatar Apr 26 '23 21:04 julianKatz