[BUG] Local mimic command `csb client bind` fails to access instance details

[kanngiesser]

Description

The default variable instance.details returns an empty map when trying to bind a service instance with the local mimic command csb client bind.

The problem occurs for our custom brokerpaks and can be reproduced for the default brokerpak which is bootstrapped from the csb pak init command

Expected Behavior

The map instance.details is expected to return output values from the provision call

Actual Behavior

instance.details returns an empty map. When testing with the default-brokerpak which is bootstrapped from the csb pak init command, calling csb client bind returns this error, for example:

{
    "url": "http://csb_user:csb_password@localhost:8123/v2/service_instances/3/service_bindings/1",
    "http_method": "PUT",
    "status_code": 500,
    "response": {
        "description": "error generating bind variables: 1 error(s) occurred: couldn't compute the value for \"address\", template: \"${instance.details[\\\"email\\\"]}\", At column 19, line 1: map \"instance.details\" does not have any elements so cannot determine type."
    }
}

Possible Fix

--

Steps to Reproduce

1. Bootstrap a new Brokerpak with the pak init command:

   mkdir sample-brokerpak
   cd sample-brokerpak
   csb pak init

2. Build the Brokerpak and start the server

   csb pak build
   csb serve

3. Provision a service instance

   csb --config client-config.yml client provision --serviceid ${SERVICEID} --planid ${PLANID} --instanceid 1 --params '{"username":"sample-user"}'

4. Create binding

   csb --config client-config.yml client bind --serviceid ${SERVICEID} --planid${PLANID} --instanceid 1 --bindingid 1

Context

The Bug prevents us from testing service bindings locally for Brokerpaks which are under development.

Your Environment

• Version used: v2.0.4
• Operating System and version (desktop): Ubuntu 22.04.4 LTS (Running from Docker image mcr.microsoft.com/devcontainers/base:jammy)
• Link to your project (if public): --
• Platform (Azure/AWS/GCP): Local Testing
• Applicable Services: Running with mariadb:11.4.2-noble backend (Docker)

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/187906362

The labels on this github issue will be updated when the story is started.

[zucchinidev]

Thank you very much for raising the incidence, @kanngiesser. We will soon prioritise tasks and analyse the issue so we can contact you as soon as possible.

[zucchinidev]

Thank you for raising the incidence. csb is a development tool that could have bugs. We are open to contributions. Unfortunately we can not allocate resources to this task right now, but we will be happy to review your pull request with some proposed solution

[kanngiesser]

After digging into the source code, this is what I was able to figure out:

• the bind request fails because the binding for our Brokerpak definition has dependencies on instance details. This is an excerpt from our service definition for an S3 bucket:

  # (...)
  bind:
  computed_inputs:
  - name: arn
    default: ${instance.details["arn"]}
    type: string

• when executing the binding operation, the service broker reads instance details from the database table service_instance_details column other_details. The bind request fails in case the binding requires instance details and service_instance_details.other_details is NULL
• service_instance_details.other_details IS NULL for all service instances after calling csb client provision

In fact, terraform outputs appear to be stored to service_instance_details.other_details only when calling GET /v2/service_instances/:instance_id/last_operation on the Service Broker (!) (see brokerapi/broker/last_instance_operation.go).

As a consequence, there is a simple fix which allows to create bindings when testing locally: call csb client last for the service instance at least once after provisioning has succeeded

[kanngiesser]

IMO this behavior appears to be somewhat unexpected and should be changed. With the current implementation, the provision request is only finalized when calling GET /v2/service_instances/:instance_id/last_operation until provisioning has succeeded.

• the GET request has side-effects and changes the state of the server. The method, thus, might not be safe
• provisioning is incomplete in case the last_operation endpoint is not called