bug: Status subresource returns 404 for any CR with Kind: Cluster

[fabriziopandini]

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]

@fabriziopandini fixed the yaml formatting for you 😄

[ncdc]

So it works as long as the Kind is not Cluster?

[yastij]

@ncdc - Yeah, we explicitly took the cowboys type, named it Cluster, from that point on, the /status subresource returns 404

[vincepri]

🤔 Might be worth adding a test case about it, could this because of the /clusters/ prefix handling?

[ncdc]

Yes please!

[yastij]

yeah, we were suspecting probably something about path resolution and handling, either regex or not expecting cluster twice

[nikhita]

/unassign @s-urbaniak
/assign

[kcp-ci-bot]

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

[kcp-ci-bot]

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