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
Will take a look next sprint.
Changing to low severity as this is not a blocker.
Will address next sprint.
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
Created attachment 1712839 [details] YAML to create a mock operator
(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.
Created attachment 1713127 [details] MockResource Operand Form
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?
(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.
Thank you Jon! Moving to VERIFIED based on comment 10 and comment 11.
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
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"