-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot watch with wildcards (across logical clusters) if the CRD hasn't been added in the admin
logical cluster
#183
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
davidfestal
added a commit
to davidfestal/kcp-kubernetes
that referenced
this issue
Oct 7, 2021
This hack: - fixes issue kcp-dev/kcp#183 - Implements a minimal support for parent cluster: the ability to manage a resource instance based on a CRD found in the parent cluster. - No default parent (as admin for example), because there are too many unsupported cases in CRD inheritance implementation: - transitive parents, - how do we delete instances on an inherited CRD ?, - ... Signed-off-by: David Festal <dfestal@redhat.com>
davidfestal
added a commit
to davidfestal/kcp-kubernetes
that referenced
this issue
Nov 4, 2021
This hack fixes issue kcp-dev/kcp#183: One cannot watch with wildcards (across logical clusters) if the CRD of the related API Resource hasn't been added in the admin logical cluster first. The fix in this HACK is limited since the request will fail if 2 logical clusters contain CRDs for the same GVK with non-equal specs (especially non-equal schemas). Signed-off-by: David Festal <dfestal@redhat.com>
ncdc
pushed a commit
to ncdc/kubernetes
that referenced
this issue
Dec 16, 2021
This hack fixes issue kcp-dev/kcp#183: One cannot watch with wildcards (across logical clusters) if the CRD of the related API Resource hasn't been added in the admin logical cluster first. The fix in this HACK is limited since the request will fail if 2 logical clusters contain CRDs for the same GVK with non-equal specs (especially non-equal schemas). Signed-off-by: David Festal <dfestal@redhat.com>
ncdc
pushed a commit
to ncdc/kubernetes
that referenced
this issue
Feb 3, 2022
This hack fixes issue kcp-dev/kcp#183: One cannot watch with wildcards (across logical clusters) if the CRD of the related API Resource hasn't been added in the admin logical cluster first. The fix in this HACK is limited since the request will fail if 2 logical clusters contain CRDs for the same GVK with non-equal specs (especially non-equal schemas). Signed-off-by: David Festal <dfestal@redhat.com>
stevekuznetsov
pushed a commit
to stevekuznetsov/kubernetes
that referenced
this issue
Jul 11, 2022
This hack fixes issue kcp-dev/kcp#183: One cannot watch with wildcards (across logical clusters) if the CRD of the related API Resource hasn't been added in the admin logical cluster first. The fix in this HACK is limited since the request will fail if 2 logical clusters contain CRDs for the same GVK with non-equal specs (especially non-equal schemas). Signed-off-by: David Festal <dfestal@redhat.com>
stevekuznetsov
pushed a commit
to stevekuznetsov/kubernetes
that referenced
this issue
Jul 13, 2022
This hack fixes issue kcp-dev/kcp#183: One cannot watch with wildcards (across logical clusters) if the CRD of the related API Resource hasn't been added in the admin logical cluster first. The fix in this HACK is limited since the request will fail if 2 logical clusters contain CRDs for the same GVK with non-equal specs (especially non-equal schemas). Signed-off-by: David Festal <dfestal@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
One cannot watch with wildcards (across logical clusters) if the CRD of the related API Resource hasn't been added in the
admin
logical cluster first.To Reproduce
Steps to reproduce the behavior:
kubectl --context=user apply -f contrib/crds/apps/apps_deployments.yaml
kubectl --context=user api-resources
=> deployments are in the API Resources list
kubectl --context=user proxy --port=8080 &
curl -v -H "X-Kubernetes-Cluster: user" http://127.0.0.1:8080/apis/apps/v1/deployments/
=> returns
{"apiVersion":"apps/v1","items":[],"kind":"DeploymentList","metadata":{"continue":"","resourceVersion":"167"}}
curl -v -H "X-Kubernetes-Cluster: *" http://127.0.0.1:8080/apis/apps/v1/deployments/
=> returns the 404 error
Expected behavior
It should return an empty list as soon as the expected CRD is found in at least one of the logical clusters.
The text was updated successfully, but these errors were encountered: