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 :)
Is your feature request related to a problem? Please describe.
The
csb clientsubcommand 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 withclient provisionandclient 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 othercsb clientcommands, namely--planidand--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.gothat the client command is a thin wrapper for an instance of the OSB client defined inpkg/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 pathGET /v2/service_instance. This follows the RESTful style used for getting a single service instance, and the way thestartServerfunction is written, it would not conflict with the other/v2commands.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 clientsubcommand. But I think it would be a better experience to have all of the client commands in one place. The downside is thatcsb clientwill 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.