Bug 1819028
| Summary: | Instances tab of a CRD will try to load with an API version that is not served | ||||||
|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Jessica Forrester <jforrest> | ||||
| Component: | Management Console | Assignee: | Yadan Pei <yapei> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Yadan Pei <yapei> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.4 | CC: | aos-bugs, jcaiani, jokerman, yapei | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.5.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Cause: used deprecated version api
Consequence: caused instances tab of crd to load with a version thats not the latest
Fix: use versions array api instead
Result: get the latest version instances for a crd
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 1822437 (view as bug list) | Environment: | |||||
| Last Closed: | 2020-07-13 17:24:11 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1822437 | ||||||
| Attachments: |
|
||||||
Hi Jessica,
I'm looking into this bug. I am able to reproduce the issue exactly as you have mentioned it above. Thanks for the detailed steps to reproduce.
A couple thoughts / questions I have now that I can see what is happening.
API:
It looks like the yaml provides a couple attributes for version which are version: string, and versions: [{name: string, served: bool, ...}].
Rules are, version must point to the first entry in the versions array. Version, however, is listed as deprecated in the docs. The docs also mention versions are sorted such that v1 > v1beta1 > v1alpha1, however, this sorting is not applied to the yaml retrieved for a CRD. Not sure if this is supposed to be supplied in order in the yaml when creating the crd or not.
So, in the case you provide, there is indeed an issue in that the explorer shows the instances of the verticalpodautoscalers crd, but the crd pages do not. The crd pages actually only use the version attribute to display data for the crd. You can see in the details page the version displays v1beta1. Same with the list page, same with the instances page whose href is -> "/k8s/all-namespaces/autoscaling.k8s.io~v1beta1~VerticalPodAutoscaler". This is the case for all crd pages.
In the explorer, however, we see that the list view shows all versions of the autoscaler crd, and thus all instances of served autoscalers are visible.
So it looks like we want to change the behavior of all the crd pages.... Would the best way to do this involve displaying all versions that are marked as served in the yaml on the crd list page, and then drill down by version from there similar to the explorer pages? It seems difficult to assess which is the once source of truth given the api docs.
Maybe this is a good question for Sam.
moving to upcoming sprint: fix for this is in code review, may not make this sprint but will make next sprint. Created attachment 1690963 [details]
Instance Tab Shows Correctly
1. Create CRD using the YAML in description
2. Goes to Instances tab, now it shows 'No VerticalPodAutoscalers Found' and a 'Create VerticalPodAutoscaler' button
loaded autoscaling.k8s.io~v1~VerticalPodAutoscaler is shown in JS console, no warnings
Verified on 4.5.0-0.nightly-2020-05-21-135919
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409 |
Create a CRD with multiple versions, the oldest of which has served:false, and going to the CRD's Instances tab will result in nothing in the tab and dev tools console showing: kindObj: no model for kind autoscaling.k8s.io~v1beta1~VerticalPodAutoscaler No model registered for autoscaling.k8s.io~v1beta1~VerticalPodAutoscaler The error also impacts the CRD UI within the Operator details page. However, if I go to the API Explorer and find one of the versions of the object that is served, I can go to its Instances tab successfully. Example of a CRD that causes the failure: --- apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: verticalpodautoscalers.autoscaling.k8s.io spec: group: autoscaling.k8s.io scope: Namespaced names: plural: verticalpodautoscalers singular: verticalpodautoscaler kind: VerticalPodAutoscaler shortNames: - vpa version: v1beta1 versions: - name: v1beta1 served: false storage: false - name: v1beta2 served: true storage: true - name: v1 served: true storage: false validation: # openAPIV3Schema is the schema for validating custom objects. openAPIV3Schema: properties: spec: type: object required: [] properties: targetRef: type: object updatePolicy: type: object properties: updateMode: type: string resourcePolicy: type: object properties: containerPolicies: type: array items: type: object