kcp
kcp copied to clipboard
kcp-dev
bug: Status subresource returns 404 for any CR with Kind: Cluster
Describe the bug
While playing around with integration between Cluster API and KCP I hit an issue where KCP returns 404 whenever we try to patch the /Status subresource on objects with Kind: Cluster.
In order to double-check the issue I have re-created the problem using wild west example and changing the Kind in it (see below)
Steps To Reproduce
Apply the following resources:
APIResourceSchema
apiVersion: apis.kcp.io/v1alpha1
kind: APIResourceSchema
metadata:
name: v230208-22d06c1f.clusters.wildwest.dev
spec:
group: wildwest.dev
names:
kind: Cluster
listKind: ClusterList
plural: clusters
singular: cluster
scope: Namespaced
versions:
- name: v1alpha1
schema:
description: Cowboy is part of the wild west
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: CowboySpec holds the desired state of the Cowboy.
properties:
intent:
type: string
type: object
status:
description: CowboyStatus communicates the observed state of the Cowboy.
properties:
result:
type: string
type: object
type: object
served: true
storage: true
subresources:
status: {}
APIExport
apiVersion: apis.kcp.io/v1alpha1
kind: APIExport
metadata:
creationTimestamp: null
name: wildwest-dev
spec:
latestResourceSchemas:
- v230208-22d06c1f.clusters.wildwest.dev
status: {}
APIBinding (if running in a workspace different than root, adjust the path accordingly)
apiVersion: apis.kcp.io/v1alpha1
kind: APIBinding
metadata:
name: wildwest-dev
spec:
reference:
export:
name: wildwest-dev
path: root
Sample Cluster
apiVersion: wildwest.dev/v1alpha1
kind: Cluster
metadata:
name: woody
spec: {}
then run
curl -k -H "Authorization: Bearer <your token>" https://192.168.1.77:6443/clusters/root/apis/wildwest.dev/v1alpha1/namespaces/default/clusters/woody/status
You will get "404 page not found"
Expected Behaviour
To be able to use custom resources of Kind: Cluster
Additional Context
No response
@ncdc - Yeah, we explicitly took the cowboys type, named it Cluster, from that point on, the /status subresource returns 404
🤔 Might be worth adding a test case about it, could this because of the /clusters/ prefix handling?
yeah, we were suspecting probably something about path resolution and handling, either regex or not expecting cluster twice
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kcp-ci-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.