Bug 1274203 - [RFE] Support Checkboxes, Radio Buttons, Drop-down lists in Openshift Templates
[RFE] Support Checkboxes, Radio Buttons, Drop-down lists in Openshift Templates
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE (Show other bugs)
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Jessica Forrester
Xiaoli Tian
Depends On:
  Show dependency treegraph
Reported: 2015-10-22 05:02 EDT by Dave McCormick
Modified: 2018-01-05 10:47 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-01-05 10:47:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave McCormick 2015-10-22 05:02:22 EDT
Description of problem:

The templating functionality included in Openshift v3 is a useful feature but lacks the power/flexibility that would make it great.

As an Openshift Systems Admininstrator, I would like to be able to offer a more complex set of templates for use by my various project teams.  In the present version I can create Text Box controls which can have a default value and translate into a variable to be used elsewhere in the template.

I would like better easier to use forms for other teams to fill out.  My urgent need is to provide multiple choice options that the developers choose from.  Some could be better expressed by checker boxes: -

Client Technologies to include in Tomcat Application Image: -
| | Oracle DBA Driver
| | AppDynamics Agent
| | Terracotta Client
| | Spring Libs

In the case of some options, I would like to offer multiple choices for the value as either radio buttons or a select pull down list. e.g. :-

Version of Terracotta Client Required: -
O 3.4.1
O 3.5.2_2
O 3.7.10
(or a pull down list)


Java Selection: -

The values selected for these controls could be mapped to variables - but in the case of the checker boxes the system would need to cater for an list of values.

There are various other common form elements, date/time pickers, multi-select list, colour picker, that could be useful in the creation of productive templates.

Template logic

Taking the idea a little further, then it would be extremely useful to be able to add logic to the template definition so that controls can be hidden or disabled based on the values of other controls, or that the data selections available can be changed.

e.g. If the '| | Oracle driver' checker box is selected then include the new form element text box 'Oracle Connection String: __________________' become visible and require a value.

e.g. If the 'Java Selection is 8' then only offer Terracotta version 3.7.10 in the pull down list of terracotta versions.

How reproducible:
Easy - does not exist.

Additional info:
Comment 3 Jessica Forrester 2018-01-02 07:58:43 EST
With the service catalog you can get a little closer to what you want.  Templates do not have pick-lists (required for either checkboxes or radio buttons) and I don't anticipate us adding that.  But the service catalog APIs allow for JSON schema for the parameters, which means you can do things like simple pick-lists and password fields. You could either do this with the ansible service broker or your own broker.

There are still gaps from what is being asked for in this RFE. Particularly changing the inputs based on previous input selections.  You could potentially do this via Plans on a service class instead if there aren't too many combinations you are trying to support.
Comment 4 Steve Speicher 2018-01-05 10:47:34 EST
Going to mark this as closed deferred since we've done all we can or plan to do for some time. There are a lot of things in this RFE that are complicated and not things we plan to support, like interdependent fields, etc.

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