Open jmcarp opened 7 years ago
By the way, I was looking at the code and wondering why it imports the cf cli instead of calling the api directly, possibly using https://github.com/cloudfoundry-community/go-cfclient. IMO the cf cli code can be less readable and harder to work with than the api.
hello @jmcarp thank for the feedback. Do you have a kind of usecase where you need this ? If you remove it actually it will do the same final effect as disabled it, no ?
About the cli, it was a choice, go-cfclient is not evolved as the cf cli is. In add, the cf cli have all the api available and have some advanced functionalities. It was a pain to do the work of "unwrap" (it's not really unwrapi cause actually the way it's written in the cli it's an API and it's not so linked to the cli) the api but in fact except things i had to do to unwrap it's pretty straight forward to read. Each verbs are easy to find now that the facade is a big example about how to do this.
Of course, you can totally say why it shouldn't be like this, i'm opened to any remarks/feedbacks
Thanks for explaining the choice about using the cli instead of the api!
Our use case is that we want to enable service access to most but not all organizations. Since we have 100+ organizations, I don't want to enable access for every single organization except for the few that shouldn't have access. Does that make sense? Maybe I'm missing a simpler solution.
yes it makes sense and i was thinking about before your answered and wanted to say that was a good idea.
It would be useful to include an equivalent of the
cf disable-service-access
command in the service broker resource--for example, to enable a service for all organizations but one. Syntax might look like:WDYT?