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.