CR scale subresources update request fails when using non-storage version's endpoint

[roycaihw]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

What happened:
When trying to update a CR's scale subresource, the update request fails if the CRD has multiple versions and the request is sent to a non-storage versions's endpoint.

What you expected to happen:
The update request succeed.

How to reproduce it (as minimally and precisely as possible):
roycaihw@71b7f5d In CRD integration subresources_test, add a second version (v1) to the CRD and mark it as the storage version. The test TestScaleSubresource still exercises on the top level version (v1beta1) and fails with:

FAIL: TestScaleSubresource (1.59s)
	subresources_test.go:291: WishIHadChosenNoxu.mygroup.example.com "foo" is invalid: apiVersion: Invalid value: "mygroup.example.com/v1": must be mygroup.example.com/v1beta1

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): from master branch HEAD
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

/assign @mbohlool
cc @sttts

[roycaihw]

/sig api-machinery

[sttts]

This is much deeper in apimachinery than #68038 suggests. It's again a case of machinery conversion code which thinks that in=Unstructured, out=Unstructured implies same GVK. Obviously this is wrong. But the code (versioning decoder in this case) skips another CR conversion step.

[liggitt]

I attempted to recreate this against master and was unable to... PUT requests to the /status subresource for both versions worked as expected for me

[sttts]

I attempted to recreate this against master and was unable to... PUT requests to the /status subresource for both versions worked as expected for me

Only scale has a problem as far as I see.

[roycaihw]

Only scale has a problem as far as I see.

You're right. I had status integration test fail for different reason. Updated the issue topic and comment

[roycaihw]

/area custom-resources
/milestone v1.12

[k8s-ci-robot]

@roycaihw: You must be a member of the kubernetes/kubernetes-milestone-maintainers github team to set the milestone.

In response to this:

/area custom-resource
/milestone v1.12

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.

[guineveresaenger]

@sttts @roycaihw this issue needs to be priority critical-urgent for it to remain in 1.12 milestone. Please check and triage.

cc @lavalamp @deads2k

[deads2k]

/priority critical-urgent

critical to CRD conversion

[guineveresaenger]

/remove-priority important-soon

[guineveresaenger]

/milestone clear
/priority important-soon
/remove-priority critical-urgent

This is related to CRD webhook versioning feature which has been pushed back to v1.13.