Service-catalog: svcat: Add broker registration/deregistration

[jeremyrickard]

svcat currently only supports relist/sync for a broker, but allows us to do pretty much everything else on other resources. Maybe we should add commands for adding/removing a broker. The cf cli allows you to do that like so...

cf create-service-broker mybrokername someuser somethingsecure https://mybroker.example.com/

I think we can add an svcat command along these lines

svcat broker add <name> --user <username> --password <password> --url <URL>

or

svcat broker add <name> --token <BEARER_TOKEN> --url <URL>

We could also allow a CA bundle to be provided (perhaps as a secret on the cluster already).

More complex scenarios might be better handled with a manifest or some other scenario (Open Service Broker for Azure provides a helm chart for example).

[carolynvs]

Here is my suggestion for the cli syntax to match how kubectl and svcat work for other commands

$ svcat register broker NAME [--cluster] [--namespace] \
  [--secret-basic SECRETNAME] [--secret-bearer SECRETNAME] \
  [--ca PEMFILE] [--skip-tls] \
  [--relist-behavior "duration|manual"] [--relist-duration "1m|2s|5hr"] \
  [--plan-restrictions "externalName in (Demo)" --plan-restrictions "name!=AABBCC"] \
  [--plan-restrictions "externalName in (Demo)" --plan-restrictions "name!=AABBCC"] \
  [--wait] [--timeout] [--interval]

$ svcat deregister broker NAME [--cluster] [--namespace] \
  [--wait] [--timeout] [--interval]

• --cluster specifies that the broker is created at the cluster level. Otherwise the namespace flag's value is used. --namespace is ignored if --cluster is set.
• --secret-basic and --secret-bearer are mutually exclusive.
• --skip-tls is a boolean and should have a message stating that --ca should be used instead. "disables TLS certificate verification when communicating with this broker. This is strongly discouraged. You should use --ca instead."
• --relist-behavior can only be either "duration" or "manual" (use the ServiceBrokerRelistBehavior consts from the catalog)
• --relist-duration should be a human readable duration value, e.g 1m = 1 minute. It cannot be set when the --relist-behavior is set to manual.
• --plan-restrictions is a string slice parameter, i.e. it can be specified multiple times. Same for --class-restrictions.
• The commands should support the waitable command interface. When --wait is specified, it should wait until the broker is ready or has failed. _We may run into trouble with the relist timeout that seems to inevitably occur on initial broker listing, I suggest we add the functionality and then deal with the odd-ball behavior in a follow up if it's a problem._

[jberkhahn]

/dibs

[carolynvs]

In addition to the flags noted above register and deregister should support the --wait related flags.

[jberkhahn]

I think this is pretty much done, so I'm closing the issue and marking it finished on the roadmap.