Bug 1854196 - Inconsistent casing on field names in the creation form for operator backed resources
Summary: Inconsistent casing on field names in the creation form for operator backed r...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.5
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.6.0
Assignee: Jon Jackson
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-06 18:02 UTC by Jessica Forrester
Modified: 2020-11-17 11:15 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Operand form generation logic was forcing "Start Case" on some field labels, but not others. Consequence: Some fields would be in original "camelCase" while others were in "Start Case". Fix: Update operand form generation logic to label form fields using unmodified "displayName" from descriptor first, then unmodified "title" from CRD schema, and finally fall back to "Start Case" CRD schema property name. Result: Unless otherwise overridden by CSV or CRD authors, all operand form field labels will be in "Start Case" by default.
Clone Of:
Environment:
Last Closed: 2020-10-27 16:12:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
keycloak auto-generated form (160.60 KB, image/png)
2020-07-06 18:02 UTC, Jessica Forrester
no flags Details
YAML to create a mock operator (13.77 KB, text/plain)
2020-08-27 15:00 UTC, Jon Jackson
no flags Details
MockResource Operand Form (201.11 KB, image/png)
2020-08-31 10:16 UTC, Yadan Pei
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 6192 0 None closed Bug 1854196: Use consistent title case for operand form labels 2020-11-17 11:11:05 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:12:46 UTC

Description Jessica Forrester 2020-07-06 18:02:24 UTC
Created attachment 1700058 [details]
keycloak auto-generated form

As an example I installed the Red Hat Single Sign-On operator, I then went to create the Keycloak resource. Some fields in the form appear with their first letter capitalized and others remain lower cased. The difference appears to be fields that are using more advanced inputs versus fields that use simple textbox inputs. See attached screenshot.




Snippet of the schema from the CRD for reference:

        spec:
          description: KeycloakSpec defines the desired state of Keycloak
          type: object
          properties:
            extensions:
              description: >-
                A list of extensions, where each one is a URL to a JAR files
                that will be deployed in Keycloak.
              type: array
              items:
                type: string
            externalAccess:
              description: Controls external Ingress/Route settings.
              type: object
              properties:
                enabled:
                  description: >-
                    If set to true, the Operator will create an Ingress or a
                    Route pointing to Keycloak.
                  type: boolean
            externalDatabase:
              description: >-
                Controls external database settings. Using an external database
                requires providing a secret containing credentials as well as
                connection details. Here's an example of such secret: 
                     apiVersion: v1     kind: Secret     metadata:         name: keycloak-db-secret         namespace: keycloak     stringData:         POSTGRES_DATABASE: <Database Name>         POSTGRES_EXTERNAL_ADDRESS: <External Database IP or URL (resolvable by K8s)>         POSTGRES_EXTERNAL_PORT: <External Database Port>         # Strongly recommended to use <'Keycloak CR Name'-postgresql>         POSTGRES_HOST: <Database Service Name>         POSTGRES_PASSWORD: <Database Password>         # Required for AWS Backup functionality         POSTGRES_SUPERUSER: true         POSTGRES_USERNAME: <Database Username>      type: Opaque 
                 Both POSTGRES_EXTERNAL_ADDRESS and POSTGRES_EXTERNAL_PORT are specifically required for creating connection to the external database. The secret name is created using the following convention:       <Custom Resource Name>-db-secret 
                 For more information, please refer to the Operator documentation.
              type: object
              properties:
                enabled:
                  description: >-
                    If set to true, the Operator will use an external database.
                    pointing to Keycloak.
                  type: boolean
            instances:
              description: Number of Keycloak instances in HA mode. Default is 1.
              type: integer
            podDisruptionBudget:
              description: Specify PodDisruptionBudget configuration
              type: object
              properties:
                enabled:
                  description: >-
                    If set to true, the operator will create a
                    PodDistruptionBudget for the Keycloak deployment and set its
                    `maxUnavailable` value to 1
                  type: boolean
            profile:
              description: >-
                Profile used for controlling Operator behavior. Default is
                empty.
              type: string

Comment 1 Jon Jackson 2020-07-07 14:13:20 UTC
Will take a look next sprint.

Comment 2 Jon Jackson 2020-07-21 23:58:41 UTC
Changing to low severity as this is not a blocker.

Comment 3 Jon Jackson 2020-07-31 19:47:09 UTC
Will address next sprint.

Comment 6 Yadan Pei 2020-08-26 08:36:15 UTC
Hi Jessica, 

Do you know how can I get Red Hat Single Sign-On operator deployed on 4.6 cluster now? Since no redhat operators are available by default in a 4.6 cluster.

I tried to build a mock operator to verify the bug but it looks like I still need a CSV file to render the operand creation form, I don't know how to create a CSV file matching the purpose of this bug

Comment 7 Jon Jackson 2020-08-27 15:00:12 UTC
Created attachment 1712839 [details]
YAML to create a mock operator

Comment 8 Jon Jackson 2020-08-27 15:36:51 UTC
(In reply to Yadan Pei from comment #6)
> Hi Jessica, 
> 
> Do you know how can I get Red Hat Single Sign-On operator deployed on 4.6
> cluster now? Since no redhat operators are available by default in a 4.6
> cluster.
> 
> I tried to build a mock operator to verify the bug but it looks like I still
> need a CSV file to render the operand creation form, I don't know how to
> create a CSV file matching the purpose of this bug

Yadan,
I've added an attachment that has some YAML for creating a "mock" operator. You will just need to create an "operand-test" project before creating these resources. To test this bug, you can go into the CSV and just remove all of the the spec descriptors since they override the field labels on the form. This will force the form to use the property names from the schema. Just make sure that the field labels still use "Start Case" capitalization instead of "camelCase" after you have removed the descriptors.

Comment 9 Yadan Pei 2020-08-31 10:16:58 UTC
Created attachment 1713127 [details]
MockResource Operand Form

Comment 10 Yadan Pei 2020-08-31 10:20:29 UTC
Thank you very much @Jon

I attached a screenshot of operand form in which all fields names are capitalized, the one 'K 8 S Resource Prefix' seems a little strange, but it seems not relate to this bug, right?

Comment 11 Jon Jackson 2020-09-01 13:25:46 UTC
(In reply to Yadan Pei from comment #10)
> I attached a screenshot of operand form in which all fields names are
> capitalized, the one 'K 8 S Resource Prefix' seems a little strange, but it
> seems not relate to this bug, right?

Correct. This behavior is a side effect of the solution. There isn't a good way to know when a schema property name is an acronym, and applying "Start Case" to those will result in strange things like 'K 8 S Resource Prefix'. The only way to fix these edge cases would be for the CSV author to override the field label with a descriptor displayName. This behavior was actually the original reason that I removed the "Start Case" logic. I was allowing the raw schema property names to be rendered to prevent this.

Comment 12 Yadan Pei 2020-09-02 01:41:46 UTC
Thank you Jon!

Moving to VERIFIED based on comment 10 and comment 11.

Comment 14 errata-xmlrpc 2020-10-27 16:12:24 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 (OpenShift Container Platform 4.6 GA Images), 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:4196

Comment 15 Alexandre Kieling 2020-11-17 11:15:52 UTC
This issue doesn't seem to be fixed in OCP 4.6.1. In my Golang operator, I define the following field:

// +operator-sdk:csv:customresourcedefinitions:type=spec,displayName="3scale APIcast Operator"
ThreeScaleAPIcastInstallationInput *ThreeScaleAPIcastInstallationInput `json:"3scale-apicast-installation,omitempty"`

and it gets rendered with the following label in the form: "3 Scale AP Icast Operator"


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