gatekeeper
                                
                                 gatekeeper copied to clipboard
                                
                                    gatekeeper copied to clipboard
                            
                            
                            
                        Allow syncing all possible resource versions
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"}
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.
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.
/reopen
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.
active
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.
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.
@anlandu @julianKatz please make sure the SyncSet design addresses this issue.
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?