[Meta] Investigate adding CF-compat API to Steward

[slack]

In this instance, Steward would be registered as to a CF cloud controller as a broker. Which would let Steward expose Kubernetes-native services back out to a CF consumer.

• Steward would respond to /v2/catalog request (Proxy the catalog API endpoint #33)
• Would expose all ServicePlans found in namespaces it was watching
• Support basic auth, configured via environment variables (just like CF) (feat(*): add CF provisoning server API #29)
• As a result, it would end up proxying any "downstream" CF brokers it was configured to talk to (feat(*): add deprovisioning endpoint and CloudFoundry implementation #43, feat(k8s,mode,web): implement unbinder and unbind API #38, feat(*): add CF provisoning server API #29, feat(cf): add binding endpoint to the CF broker API proxy #34)

[arschles]

A few considerations:

• Since each running steward can service a subset of the cluster-global catalog, each will return their own serviceable subset
• As a result of the previous, stewards cannot be run behind a k8s service, as each request will be routed to a random steward

[arschles]

Issue for the provisioning API: #28

[arschles]

Issue for binding API: #31

[arschles]

Issue for listing steward IPs in the service catalog: #32

[arschles]

@slack three of the four bullet points in the PR description are complete. However, I want to get more details on the meaning of this one: Would expose all ServicePlans found in namespaces it was watching

Currently, steward does the below steps on startup. Do these fulfill the requirements in that bullet point? :

• Calls /v2/catalog on the backing CF broker
• Converts the response to a list of ServiceCatalogEntrys (ServiceCatalogEntry is the 3PR representing the catalog)
• Writes each ServiceCatalogEntry into the steward namespace

Note that steward does not currently watch any namespaces until #17 and related issues are resolved.

[slack]

That was covering the scenario where an SB client is talking to a steward in CF mode. The CF-mode steward's /v2/catalog response would be a collection of all of the ServicePlans 3PRs that the Steward could "see". That deployment scenario would expose all of the services currently registered in the cluster to a consumer off-cluster.

Our proxy mode is subtly different, and I think we can strike that requirement.

[arschles]

This has been finished by all PRs referenced herein