Bug 1819028 - Instances tab of a CRD will try to load with an API version that is not served
Summary: Instances tab of a CRD will try to load with an API version that is not served
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.5.0
Assignee: Yadan Pei
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks: 1822437
TreeView+ depends on / blocked
 
Reported: 2020-03-31 01:18 UTC by Jessica Forrester
Modified: 2020-07-13 17:24 UTC (History)
4 users (show)

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
Clone Of:
: 1822437 (view as bug list)
Environment:
Last Closed: 2020-07-13 17:24:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Instance Tab Shows Correctly (102.48 KB, image/png)
2020-05-22 05:48 UTC, Yadan Pei
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 5355 0 None closed Bug 1819028: Fix instances / version issue with crd pages 2020-06-28 06:37:23 UTC
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-07-13 17:24:31 UTC

Description Jessica Forrester 2020-03-31 01:18:24 UTC
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

Comment 1 Joe Caiani 2020-04-13 22:02:13 UTC
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.

Comment 2 Joe Caiani 2020-05-08 16:56:36 UTC
moving to upcoming sprint: fix for this is in code review, may not make this sprint but will make next sprint.

Comment 6 Yadan Pei 2020-05-22 05:48:58 UTC
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

Comment 8 errata-xmlrpc 2020-07-13 17:24:11 UTC
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


Note You need to log in before you can comment on or make changes to this bug.