Support for dynamic parameters in an APB

[maleck13]

Feature:

I am exploring the idea of allowing a user to specify a set of dynamic values (similar to how env vars are specified in the OpenShift UI) as part of provisioning a service. This would need to be able to defined as part of the apb.yaml file.
It is a relatively custom use case, but I wondered what others thought of this as an option for APB developers.
The use case is
As an APB developer, I want to allow a user to set an arbitrary number of key value pairs which I can use as part of provisioning my service.
More specifically, I am thinking about mobile developers within an organisation that already has existing business logic in existing applications but now wants that exposed to their mobile client.
One option I am considering for achieving this is creating a "Custom Service Connector" APB that abstracts the underlying requirement for creating secrets and configmaps and labeling them correctly and just asks the developer for the information they should know such as the host, and then allow them to configure a set of key value pairs that would contain any additional configuration, such as an API Key.
The APB would set up these objects and label them as needed and their service would appear as a service instance in their namespace.

[rthallisey]

From the kubevirt perspective, they need some parameters to be populated before the APB is launched based on what resources are available in the cluster. For example. to launch a vm I need to know the list of images I have available. The UI should have a menu that is dynamically populated based on the physical volumes in the cluster.

There might be some overlap here between what mobile and kubevirt need.

[maleck13]

Yes perhaps something along the lines of

- type: dynamic
      provider: user
      name: config

or

- type: dynamic_map
      provider:user
      name: config

[rthallisey]

When an icon is selected in the UI, a menu will be populated with the names of pvs from the kubesystem-namespace

- type: dynamic
      resource: pv
      namespace: kube-system

[maleck13]

@spadgett ping would love your thoughts on this or perhaps direction as to whom it would be discuss it with from a UI perspective

[mhrivnak]

I used a pattern recently that may be helpful. It's not lovable, nor elegant, but it is simple and effective.

I had a provision workflow that required arbitrary data to be passed as YAML. Before the broker got involved, an end user was expected to grab an example YAML file that had default values, change them as appropriate, then provide that YAML to the provision action of this sr.

In my service bundle, I made a plan with a parameter whose type is string, display_type is textarea, and the default value is the contents of that default YAML document. In the openshift UI, the user sees a text area with the default YAML pre-populated, and they can edit it however they like.

So you can invite users to provide key-value data in a format of your choice in a text area, then parse it at provision time. It's not the greatest UX, but you can do it today without change to broker code or the OSB API.

[maleck13]

@mhrivnak thanks for the option. I will keep this in mind. It might provide us with a mechanism for doing this currently while working on getting a better long term solution accepted

[jwmatthews]

In addition to the use case described in original comment, below are some other thoughts we've had on "dynamic parameters".

Several product teams have expressed the desire to have parameters of a Plan to be updated based on either input from an end user or from introspecting an environment.

Example #1
Consider if a user is interacting with an AWS APB.
If the user selects "us-east-1" region, we'd want a subsequent parameter for "security-group" to be pre-populated with a dropdown menu of the existing security-groups available to the API credentials in us-east-1. (Would be great if we could run code on ui side from an APB, think what if an APB could contain an optional webcomponent that could be injected into the UI and begin to provide a 'custom ui'...)

Example #2
Consider interaction with OpenStack VM service, an APB is built to represent VMs that may be requested. We'd like the end user to see different plans that reflect the images available, the data for the VM images available would need to be determined from talking to OpenStack APIs.

For #1 we'd ideally like a mechanism that would allow logic to run from UI side so we have complete control of looking at input while user enters it, then run some logic to compute/validate other parameters. (Rough guess is the scope of achieving this will be difficult, we'd like to begin some R&D work looking at possible paths but don't see this as achievable in short-term).

For #2 we can likely add some logic to the broker to run another kind of action on an APB and consult the output to build up the plans/parameters in a dynamic manner.

[gtema]

For openstack-service-broker we were thinking of deploying configmap with connection configuration to the cloud, and then for individual resources (APB) you would want to look, which clouds are configured and populate the select box, or what was already mentioned, check whether particular objects already exists in this cloud.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[jmrodri]

/close

[openshift-ci-robot]

@jmrodri: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.