Clarification: Why does the controller implement the CF service broker API?

[krancour]

The controller/server package seems to implement the CF service broker API. Our (Deis') understanding is that the controller's responsibility is only to watch k8s resources and reify based on events affecting those resources. This obviously does require the controller to act as a client in its interaction with brokers that do implement the CF service broker API, but it's not clear why the controller itself implements a server listening on the endpoints described by that API. Can anyone clarify the reasoning behind this? What is the client that we anticipate being on the other end of such an interaction?

[pmorie]

Good question. I do not think ultimately any controller in service-catalog should implement this or any other service broker API. Perhaps @vaikas-google or @bmelville can comment on this?

[martinmaly]

Even though the API which the controller implements is not CF service broker API (I am assuming the API implementation @krancour refers to is:
https://github.com/kubernetes-incubator/service-catalog/blob/master/controller/server/server.go#L59) - it is a similar HTTP/JSON api which implements the functionality of registering brokers, creating instances (in a broker-agnostic way) and bindings. It is essentially another frontend to the k8s resources watcher code. The HTTP/JSON api predates the k8s resources watcher and should be probably removed as it doesn't apply to k8s catalog.

[krancour]

@martinmaly thanks for the explanation. Upon closer examination, I see you're correct that it's not the CF service broker API, but rather an API that looks similar.

The HTTP/JSON api predates the k8s resources watcher and should be probably removed as it doesn't apply to k8s catalog.

I would agree. I'll close this and open a separate issue requesting its removal.

[pmorie]

@martinmaly @krancour Sounds like this is going to be subsumed by the API server we create.