[FR] Add csb client list command to CLI

[jameshochadel]

Is your feature request related to a problem? Please describe.

The csb client subcommand is very useful for local development of brokerpaks. However, it does not support listing instances present in the database. It is easy to create new cloud resources with client provision and client bind, but if I do not write down the GUIDs of the instances I create, it is not easy to clean them up later.

Describe the solution you'd like

I propose adding a new subcommand, csb client list, to the Cloud Service Broker CLI. The command would take similar flags to the other csb client commands, namely --planid and --serviceid. The command could list all instances in the broker database if no flags are provided, and/or narrow down its response if the flags are provided.

I can see in cmd/client.go that the client command is a thin wrapper for an instance of the OSB client defined in pkg/client/client.go. The OSB API does not define a list command, so I propose redefining the Client struct as implementing a superset of the OSBAPI, including this new List function.

On the server side, I propose registering a new route in cmd/serve.go:startServer() with path GET /v2/service_instance. This follows the RESTful style used for getting a single service instance, and the way the startServer function is written, it would not conflict with the other /v2 commands.

I haven't gone deeper to determine where the actual function that queries the database should go, but I'm happy to do so if the maintainers think this feature is a good idea.

Describe alternatives you've considered

Alternatively, the command could be added outside the csb client subcommand. But I think it would be a better experience to have all of the client commands in one place. The downside is that csb client will have some commands that are OSBAPI-standard and one that is not. Since the client is not meant to be a generic OSBAPI client, but rather a client specifically for the CSB, I think this is fine. But I'd welcome feedback!

As an alternative implementation to redefining the meaning of the client in pkg/client/client.go, one could define a new "CSB Client" somewhere and embed the OSBAPI client within it. This could be desirable if there are other usages of the OSBAPI client that rely on the existing semantics. (No existing methods would be changed by this proposal, but the abstraction would be muddied.)

Additional Context

n/a.

Priority

Low.

Priority Context

Not urgent, but I'm interested in making this contribution myself. I wanted to open a conversation about the design & desirability of the feature here with the maintainers :)

Platform

Applies to all platforms.

Applicable Services

Applies to all services.

[kanngiesser]

Hi @jameshochadel,
the /v2/service_instance is defined as part of the Open Service Broker API Specification. The implementation for the Cloud-Service-Broker already contains some boilerplate-code for the resolver and for tests.

I needed to implement this endpoint because the functionality is needed by our team. Feel free to review the MR and leave some comments.

As far as I could figure out, the functionality to fetch an instance (or a binding) or to list all instances is still missing. IMO, this functionality would be pretty useful for testing and debugging. As far as I could figure the code to implement this needs to go here and here.