Prepare backend for changes in binding flow

[derberg]

Confirm these statements before you submit the issue:

• I have searched open and closed issues for duplicates.
• I have read the contributing guidelines.

---

Description

• make sure we have query for ServiceBindingUsages and are able to fetch the following information in the context:
  • name of the usage
  • bound application/resource and its kind
  • name of service binding used by the usage
  • secret of the service binding
  • status type and message
• make sure we have query for ServiceBindings and are able to fetch the following information in the context:
  • name of the binding
  • secret
  • status type and message
  • extra para
  • get also a total number servicebindings that failed (red) or have issue (yellow). This could also be done server side, no need to have such counter logic client side
• make sure we can fetch not only plan's schemas.service_isntance but also schemas.service_binding
• make sure we have mutation for ServiceBinding so we are able to create a binding, providing also custom parameters if such are provided
  • response from the server should contain the name of the newly created servicebinding
  • name generation is handled server side
• make sure we have mutation for ServiceBindingUsage so we are able to create a binding usage
  • response from the server should contain the name of the newly created usage
  • name generation is handled server side
  • setting prefix is possible
• make sure we can query for all resources of a given kind defined by UsageKind, in namespace context. So that we can for example get names of all available Deployments, and Functions and more, if defined. So if new UsageKind Configuration is defined, I can query for all its resources and list them. The querying will not be triggered from UI as it is now, that first you specify kind, but query will fetch all kinds and its resources at the same time.

The subscription part to enable UI to display those details using websockets is handled here #269

Reasons

• enable UI for development
• split of view of usages vs bindings

Attachments

Below attachments are for reference to show what details are needed in the UI

[PK85]

about SBU and SB name generation, consider:

• use prefix which is a service instance name
• k8s generatedName vs docker container default naming

fetching UsageKinds and instances, consider:

• one query vs two queries (UK and then aggregated call for instances), consult with UI team

check how get values of service binding input parameters (probably same as for service instances)

[piotrmiskiewicz]

• ServiceBindingUsage query
• ServiceBindings query, needs metrics (total number of failed etc.) and extra para Expose bindings stats via ui-api-layer #969
• ServicePlan needs schemas.service_binding Expose ServicePlan createSB schema via ui-api-layer #933
• mutation for ServiceBinding so we are able to create a binding, providing also custom parameters if such are provided, name generation is handled server side Enhance SB/SBU mutations #937
• mutation for ServiceBindingUsage so we are able to create a binding usage, name generation is handled server side, setting prefix is possible Enhance SB/SBU mutations #937
• query for all resources (of every UsageKind) in namespace context: Add bindable resources endpoint #877

[piotrmiskiewicz]

Both SB and SBU can have generated name (if name is not provided in the input). The generated format is: randomword-randomword

[piotrmiskiewicz]

Needs to be done:

1. follow up task: remove query usageKindResources (can be done after ui console changes) - created Remove deprecated usageKindResources query from ui-api #1097
2. add displayName (invent name) in bindableResources query Improve binding resources queries in ui-api #1084
3. Field serviceBindings/serviceBindings should be changed to serviceBindings/Items Improve binding resources queries in ui-api #1084
4. Add extra binding params values to the serviceBinding response Improve binding resources queries in ui-api #1084