In integration test rather than sleeping certain amount of time to wait create/delete instance/binding to finish, we need to add status polling. GKE catalog should have exposed API for that, and this issue should to be able to be fixed when we switching from cmd to go lib.

Dry-run mode can be used for users to learn what sc does before actually installing something into their clusters.

Need to Enable bigtable API, otherwise bigtable instance deployment hit below error
Also it looks like we also didn't enable pubsub API right now, it should be done during add-gcp-broker ?
requiredAPIs := []string{
gcp.DeploymentManagerAPI,
gcp.ServiceBrokerAPI,
gcp.ServiceRegistryAPI,
}
err = gcp.EnableAPIs(requiredAPIs)

z4006102b-905e-4712-84c0-8e0b2d16e12f has resource warnings
instance_creation: {"ResourceType":"gcp-types/bigtableadmin-v2:bigtableadmin.projects.instances.create","ResourceErrorCode":"403","ResourceErrorMessage":{"code":403,"message":"Cloud Bigtable Admin API has not been used in project quanlin-gke-e2e5 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/bigtableadmin.googleapis.com/overview?project=quanlin-gke-e2e5 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.","status":"PERMISSION_DENIED","details":[{"@type":"type.googleapis.com/google.rpc.Help","links":[{"description":"Google developers console API activation","url":"https://console.developers.google.com/apis/api/bigtableadmin.googleapis.com/overview?project=quanlin-gke-e2e5"}]}],"statusMessage":"Forbidden","requestPath":"https://bigtableadmin.googleapis.com/v2/projects/quanlin-gke-e2e5/instances","httpMethod":"POST"}}

I have a GKE cluster running 1.8.4 with legacy auth disabled
I have a cluster admin role. I prove that I have full access with

$ kubectl auth can-i '*' '*' --all-namespaces
yes

I run sc install and get the error clusterroles.rbac.authorization.k8s.io "etcd-operator" is forbidden

I don't know what I'm missing.

Role binding command:

$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=`gcloud config config-helper --format=json | jq '.configuration.properties.core.account'`
clusterrolebinding "cluster-admin-binding" created

Full output:

$ sc install
generated service catalog deployment config in dir: /tmp/service-catalog898278198
Service Catalog could not be installed
error deploying YAML files: deploy failed with output: exit status 1 :Error from server (Forbidden): error when creating "/tmp/service-catalog898278198/etcd-operator-rbac.yaml": clusterroles.rbac.authorization.k8s.io "etcd-operator" is forbidden: attempt to grant extra privileges: [PolicyRule{Resources:["etcdclusters"], APIGroups:["etcd.database.coreos.com"], Verbs:["*"]} PolicyRule{Resources:["customresourcedefinitions"], APIGroups:["apiextensions.k8s.io"], Verbs:["*"]} PolicyRule{Resources:["storageclasses"], APIGroups:["storage.k8s.io"], Verbs:["*"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["services"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["endpoints"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["persistentvolumeclaims"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["events"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["deployments"], APIGroups:["apps"], Verbs:["*"]}] user=&{[email protected]  [system:authenticated] map[]} ownerrules=[PolicyRule{Resources:["selfsubjectaccessreviews"], APIGroups:["authorization.k8s.io"], Verbs:["create"]} PolicyRule{NonResourceURLs:["/api" "/api/*" "/apis" "/apis/*" "/healthz" "/swagger-2.0.0.pb-v1" "/swagger.json" "/swaggerapi" "/swaggerapi/*" "/version"], Verbs:["get"]}] ruleResolutionErrors=[]

$ sc add-gcp-broker

using project:  [MY_PROJECT_NAME]                                                                                                                   
enabled required APIs  [deploymentmanager.googleapis.com servicebroker.googleapis.com serviceregistry.googleapis.com]                                 
error fetching service account :failed to retrieve service account : exit status 1:generated the key at : /tmp/service-catalog-gcp903543596/key.json  
GCP broker added successfully.  

Can we remove "exit status 1:" message? This is not a real error. The installer has a logic to create a service account when it does not exist.

sc install command requires a permission (clusterrolebinding) in kubectl. But, the error message from sc is not descriptive nor human readable. sc can output something like "Please run kubectl ...".

The current error message is:

generated service catalog deployment config in dir: /tmp/service-catalog305310769
Service Catalog could not be installed
error deploying YAML files: deploy failed with output: exit status 1 :Error from server (Forbidden): error when creating "/tmp/service-catalog305310769/etcd-operator-rbac.yaml": clusterroles.rbac.authorization.k8s.io "etcd-operator" is forbidden: attempt to grant extra privileges: [PolicyRule{Resources:["etcdclusters"], APIGroups:["etcd.database.coreos.com"], Verbs:["*"]} PolicyRule{Resources:["customresourcedefinitions"], APIGroups:["apiextensions.k8s.io"], Verbs:["*"]} PolicyRule{Resources:["storageclasses"], APIGroups:["storage.k8s.io"], Verbs:["*"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["services"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["endpoints"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["persistentvolumeclaims"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["events"], APIGroups:[""], Verbs:["*"]} PolicyRule{Resources:["deployments"], APIGroups:["apps"], Verbs:["*"]}] user=&{REDACTED  [system:authenticated] map[]} ownerrules=[PolicyRule{Resources:["selfsubjectaccessreviews"], APIGroups:["authorization.k8s.io"], Verbs:["create"]} PolicyRule{NonResourceURLs:["/api" "/api/*" "/apis" "/apis/*" "/healthz" "/swaggerapi" "/swaggerapi/*" "/version"], Verbs:["get"]}] ruleResolutionErrors=[]

sc install RBAC roles needs to be updated to be in sync with this commit kubernetes-retired/service-catalog@617c823#diff-afa9a5f81c77e25727041afe3f570930

EnableAPIs is called here, with err getting the value. err is then overwritten without the EnableAPIs err return getting checked.

https://github.com/GoogleCloudPlatform/k8s-service-catalog/blob/32c81063d47ae09c33c1a39eba5e8a5313e52af0/installer/pkg/cmd/gcp_broker.go#L69-L76

cc @cholick

Service Catalog will only work 1.7+ cluster. sc install should perform check before starting the install process.

The error message is:

$ ./sc install
generated service catalog deployment config in dir: /tmp/service-catalog205418802
Service Catalog could not be installed
error deploying YAML files: deploy failed with output: exit status 1 :error: unable to recognize "/tmp/service-catalog205418802/api-registration.yaml": no matches for apiregistration.k8s.io/, Kind=APIService

$ gcloud container clusters list
NAME ZONE MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS
REDACTED us-west1-a 1.6.10-gke.1 REDACTED n1-standard-1 1.6.10 * 3 RUNNING

sc install --interactive asks "[Y/n]" for each step with the commands that sc will run.

For example,
sc prints Run "kubectl create -f /tmp/xxx/abc.yaml" [Y/n]", and waits for a user's input. The user can lookup abc.yaml before moving on.

Google Cloud Service Registry API has not been used in project ypcloud-io before or it is disabled.

can't find Google Cloud Service Registry API in the library and get

The API "serviceregistry.googleapis.com" doesn't exist or you don't have permission to access it

Tried both on minikube and GKE with RBAC enabled. Same errors in both cases. Our gcp project and account is enabled with EAP google service broker apis.

kubectl logs google-oauth-794d794cc5-9fpc7 namespace=service-catalog
I1219 21:41:29.861458       1 reflector.go:196] Starting reflector *v1.Secret (10m0s) from plori/catalog-oauth/watcher/watcher.go:35
I1219 21:41:29.864011       1 reflector.go:234] Listing and watching *v1.Secret from plori/catalog-oauth/watcher/watcher.go:35
I1219 21:41:30.157515       1 round_trippers.go:405] GET https://10.96.0.1:443/api/v1/secrets?resourceVersion=0 403 Forbidden in 293 milliseconds
E1219 21:41:30.157883       1 reflector.go:199] plori/catalog-oauth/watcher/watcher.go:35: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:service-catalog:controller-manager" cannot list secrets at the cluster scope

For mutual TLS to work between Kubernetes API server and Service Catalog Server,

extension-apiserver-authentication ConfigMap should have appropriate request-header-* keys populated. This dependency can be checked before the service catalog install command.

The broker-cli tool allows for debugging and managing brokers from the Google Cloud Service Broker API. It uses the existing broker-cli library already existing as part of the installer.

Introduction of this tool will require the following steps:

• Refactor existing broker-cli code out of installer into its own top-level directory
• Vendor broker-cli library into installer to decouple
• Remove old broker-cli from installer/pkg
• Introduce recent changes/additions to the library to support the tool
• Introduce the tool itself

Example instance template -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
name: gcp-bigtable-instance-10212
namespace: gcp-apps
spec:
serviceClassName: bigtable
planName: 20171020-00
parameters:
instance:
type: PRODUCTION # no downgrade allowed from PRODUCTION to DEVELOPMENT.
clusters:
my-bt-cluster: # Bigtable cluster name.
defaultStorageType: SSD # no change after creation.
serveNodes: 3 # can only specified in PRODUCTION instance type.
location: us-central1-b
tables: # Bigtable table schema. It's optional.
my-bt-table: # my-bt-table table with foo, bar, and haha column-families.
granularity: MILLIS
columnFamilies:
foo:
gcRule:
maxNumVersions: 2
bar:
gcRule:
maxNumVersions: 2
haha:
gcRule:
maxNumVersions: 10
my-bt-table2: # second table.
granularity: MILLIS

Example binding template -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstanceCredential
metadata:
name: gcp-bigtable-binding-201710211
namespace: gcp-apps
spec:
instanceRef:
name: gcp-bigtable-instance-10212
secretName: gcp-bigtable-credentials
parameters:
serviceAccount: "[email protected]"
bindingType: user

sc install should abort the installation if storage-class required for etcd-cluster is not present.

Heads up :
currently sc installer calls serviceregistry API to create virtual broker.
since we're only do beta release for service broker API(not service registry), service broker has a copy of createbroker which is available to for sc installer to call, sc installer will need to switch.

due to prod freeze during thanksgiving and kubecon, this change hasn't been rolled out to prod yet, will update here once the change is in prod and available for sc installer to test

// CreateBroker creates a broker in project with the given name, title, and catalogs using the registryURL.
func (adapter *HttpAdapter) CreateBroker(params *CreateBrokerParams) ([]byte, error) {
url := fmt.Sprintf("%s/v1alpha1/projects/%s/brokers", params.RegistryURL, params.Project)

sc install --verbose shows detailed information of each step including kubectl and gcloud commands with the output of the commands.

integration test needs to verify resource create/delete successfully from deployment manager side

currently when ./test/e2e.sh finished successful, from pantheon, binding deployment is deleted as expected, however instance deployment still there.

Currently sc install is using custom service-catalog build because async binding support was there in OSS service catalog releases. 0.1.3+ onwards, async binding support is added, so sc should start using OSS releases going forward.

Can we add version command to show the build details of sc binary?
It would be useful for debugging purpose.

Example storage instance template -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
name: gcp-storage-instance-10211
namespace: gcp-apps
spec:
serviceClassName: storage
planName: 20171020-00
parameters:
location: US
storageClass: STANDARD

Example storage binding template -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
name: gcp-storage-instance-10211
namespace: gcp-apps
spec:
serviceClassName: storage
planName: 20171020-00
parameters:
location: US
storageClass: STANDARD

If the command-line user does not have the "cluster-admin" role, then she will not be able to set the RBAC roles for service catalog. The error message has the following snippet:

...forbidden: attempt to grant extra privileges...

This error should include the necessary fix:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin [email protected]

we have published new version(see blow) of pubsub service definition to registry,
plans:

• bindable: true
  description: See plan name for release date.
  externalID: faa33be7-d48b-4aab-a5b6-3d96b44ed260
  externalMetadata: null
  free: true
  instanceCreateParameterSchema: {}
  instanceUpdateParameterSchema: {}
  name: 20171020-00
  serviceInstanceCredentialCreateParameterSchema:
  properties:
  bindingType:
  description: |
  The type of this binding. Affects the level of access granted to the service account.
  enum:
  - publisher
  - subscriber
  type: string
  serviceAccount:
  description: Service account to which access will be granted.
  type: string
  required:
  • bindingType
  • serviceAccount

Need to update

1. planName in gcp-pubsub-instance.yaml
2. bindingType is a required property in gcp-pubsub-binding.yaml,

example instance yaml file -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
name: gcp-pubsub-instance-10211
namespace: gcp-apps
spec:
serviceClassName: pubsub
planName: 20171020-00

example binding yaml file -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstanceCredential
metadata:
name: gcp-pubsub-binding-2017102101
namespace: gcp-apps
spec:
instanceRef:
name: gcp-pubsub-instance-10211
secretName: gcp-pubsub-credentials
parameters:
# GCP app service account
serviceAccount: "[email protected]"
# publisher or subscriber
bindingType: subscriber

I'm trying to do a walkthrough of the system. While the README.md has a lot of good information, I am finding a few things:

1. I have to piece together all the right steps from error messages and different sections
2. I don't really get the what and why of what's going on
3. I don't know what to do after sc install and sc add-gcp-broker

Do we have plans to open source the pubsub demo app and perhaps include it as part of a comprehensive walkthrough?

I got:

⦿ sc check
Dependency check passed. You are good to go.

But had:

⦿ cfssl
Killed: 9
⦿ cfssljson
Killed: 9

So the binarys were broken but the sc check passed.

Im using service catalog for the first time. I saw a lot APIs provided by Cli commants. Is there any Rest APIs provided too?

My installation failed because I had not granted cluster admin access to myself. Running install again caused this failure:

$ sc install
generated service catalog deployment config in dir: /tmp/service-catalog021394536 
Service Catalog could not be installed
error deploying YAML files: deploy failed with output: exit status 1 :Error from server (AlreadyExists): error when creating "/tmp/service-catalog021394536/namespace.yaml": namespaces "service-catalog" already exists

I tried sc uninstall but it didn't clean up the namespace. It would be great to either have

1. Uninstall clean up the namespace, or,
2. Install re-use the namespace if it exists.

When running sc add-gcp-broker, it failed in gcloud command, but it only shows the following error message:

using project:  [REDACTED]                                                                                                                   
enabled required APIs  [deploymentmanager.googleapis.com servicebroker.googleapis.com serviceregistry.googleapis.com]                                 
failed to configure GCP broker                                                                                                                        
error creating service account key :failed to create service account key:  : exit status 1  

We should also collect the error message of gcloud command, and show them when we run sc with verbose mode (or even by default).

$ gcloud beta iam service-accounts keys create --iam-account [REDACTED] /tmp/service-catalog-gc\p294682850/key.json                                                           

ERROR: (gcloud.beta.iam.service-accounts.keys.create) RESOURCE_EXHAUSTED: Maximum number of keys on account reached.                                  
- '@type': type.googleapis.com/google.rpc.RetryInfo                                                                                                   
  retryDelay: 86401s                                                                                                                                  
- '@type': type.googleapis.com/google.rpc.DebugInfo                                                                                                   
  detail: '[ORIGINAL ERROR] generic::resource_exhausted: Maximum number of keys on                                                                    
    account reached. [google.rpc.error_details_ext] { message: "Maximum number of                                                                     
    keys on account reached." details { type_url: "type.googleapis.com/google.rpc.RetryInfo"                                                          
    value: "\n\004\010\201\243\005" } }' 

Per instructions on installer's README https://github.com/GoogleCloudPlatform/k8s-service-catalog/blob/master/installer/README.md, go get should successfully compile sc command. Results are below compilation failure:

go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
package broker-cli/auth: unrecognized import path "broker-cli/auth" (import path does not begin with hostname)
package broker-cli/client/adapter: unrecognized import path "broker-cli/client/adapter" (import path does not begin with hostname)

It's a proposal by Sean/Sunil. They told me that there're Google libraries that can replace gcloud command runs.

By doing so, sc installer will be more robust especially when gcloud makes a breaking change.

I ran sc install after sc check passed and skipped the command kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account), so it printed out the following error message:

maqiuyu-macbookpro:installer maqiuyu$ ./output/bin/sc install
generated service catalog deployment config in dir: /tmp/service-catalog497921935
Service Catalog could not be installed
Error: error deploying YAML files: deploy failed with output: exit status 1 :Error from server (Forbidden): error when creating "/tmp/service-catalog497921935/etcd-operator-rbac.yaml": clusterroles.rbac.authorization.k8s.io "etcd-operator" is forbidden: attempt to grant extra privileges: [PolicyRule{Resources:["etcdclusters"], APIGroups:["etcd.database.coreos.com"], Verbs:[""]} PolicyRule{Resources:["customresourcedefinitions"], APIGroups:["apiextensions.k8s.io"], Verbs:[""]} PolicyRule{Resources:["storageclasses"], APIGroups:["storage.k8s.io"], Verbs:[""]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:[""]} PolicyRule{Resources:["services"], APIGroups:[""], Verbs:[""]} PolicyRule{Resources:["endpoints"], APIGroups:[""], Verbs:[""]} PolicyRule{Resources:["persistentvolumeclaims"], APIGroups:[""], Verbs:[""]} PolicyRule{Resources:["events"], APIGroups:[""], Verbs:[""]} PolicyRule{Resources:["deployments"], APIGroups:["apps"], Verbs:[""]}] user=&{[email protected] [system:authenticated] map[]} ownerrules=[PolicyRule{Resources:["selfsubjectaccessreviews"], APIGroups:["authorization.k8s.io"], Verbs:["create"]} PolicyRule{NonResourceURLs:["/api" "/api/" "/apis" "/apis/" "/healthz" "/swaggerapi" "/swaggerapi/" "/version"], Verbs:["get"]}] ruleResolutionErrors=[]

We might want to make some suggestions based on the error in addition to the error message itself.

Currently the sc update command is minimal update which only modifies the current service catalog container image. It runs a kubectl set image ... command. Eventually, we will need an update which performs all the actions needed to upgrade to a new version (or roll back). For example, if a new RBAC role is added for the next version of service catalog, then this role should be applied; it currently won't be. There are a couple avenues to explore here:

1. Once the concept and abstractions of an application are added to Kubernetes, we can leverage these. The Kubernetes application working group is attempting to define these now.
2. Perform a complete kubernetes apply ... command on a set of complete generated YAML files. The current installer basically does this now, but only for sc install and sc add-gcp-broker--not for sc update

If running sc add-gcp-broker && sc remove-gcp-broker multiple times, it will eventually fail.
It's because sc add-gcp-broker creates a private key of a service account while sc remove-gcp-broker does not clean it up.

Similarly, we should make sc install && sc uninstall idempotent as well.

Example instance template -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
name: gcp-bigquery-instance-10211
namespace: gcp-apps
spec:
serviceClassName: bigquery
planName: 20171020-00
parameters:
dataset:
datasetReference:
datasetId: perrito

Example binding template -
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstanceCredential
metadata:
name: gcp-bigquery-binding-201710211
namespace: gcp-apps
spec:
instanceRef:
name: gcp-bigquery-instance-10211
secretName: gcp-bigquery-credentials
parameters:
serviceAccount: "[email protected]"
bindingType: OWNER

sc install failed with the following reason even if sc check succeeded:

Service Catalog could not be installed
Error: error generating YAML files: error generating SSL artifacts : error generating ca: stdout: stderr:

cfssl tools seem to be the root cause. Ran ./cfssl under $GOPATH/bin and got:

Killed: 9

OS: macOS High Sierra Version 10.13.2
Workaround: Under $GOPATH/bin, do rm cfssl*, and install cfssl tools manually: go install -ldflags -s github.com/cloudflare/cfssl/cmd/....
Note: After I ran the workaround for the first time, ./cfssl worked but sc install still failed. Then I did the workaround again, and this time sc install succeeded. Not sure what happened.

I don't know why this issue happens, and whether the issue and workaround are reproducible. But for the convenience of future users, we might want to fix it.

While kubectl get is being improved, we can make a quick improvement via sc CLI.
In this subcommand, we want to support at least 3 functionalities:

• Check if GCP broker is good: sc get brokers
• Get a list of service classes: sc get classes or sc get services
• Get a list of service plans given a [SERVICE_CLASS]: sc get plans --service=[SERVICE_CLASS]
• Get input parameters of a plan: sc describe plans [PLAN_NAME] --service=[SERVICE_CLASS]

It's a proposal by Sean/Sunil. They told me that cfssl library exists, though they said the library is not very easy to use.. The benefit of doing it is to make sc installer robust when cfssl makes a breaking change.

After the fix, we will be able to remove go get -u github.com/cloudflare/cfssl/cmd/... step.

We observed the following scenarion on our cluster today.

At some point in the past, we used a very old version of sc to install service catalog which created APIService object for v1alpha1. We upgraded sc version corresponding to v1beta1 version of service catalog and then ran uninstall command and found that it deletes APIService object corresponding to v1beta1 not v1alpha. So v1alpha1 APIService objects stays there. Now when you run sc install, it will create APIService object for v1beta1 and you end up with API Service object for service catalog. As a result of this, controller-manager will try to access v1alpha1 while listing all the versions and fail listing v1alpha1 version and run in to a crashloop forever.

In the "add-gcp-broker" sub-command, a service account is created (if it doesn't already exist) and a JSON key for this service account is created and downloaded. Currently, we don't remove/delete this key from the service account when we call "remove-gcp-broker". Only about a dozen keys are allowed for a service account, so we eventually run out of keys for the service account and throw an error.

"sc install" implicitly uses gcloud config including project and zone. It would be better if "sc check" explicitly shows the gcloud configuration that will be used.

We can get the configuration via gcloud config list. I think we can print "account" (GCP user email) as well.

sc should support an update subcommand to address the following:

• upgrade service catalog components (apiserver/controller release updates)
• upgrade etcd version
• upgrade etcd-operator version
• upgrade auth manager version

So subcommand structure should be:

sc update

Examples:
sc update service-catalog apimanager=gcr.io/apiserver:0.1.0 controllermanager=quay.io/controller-manager:0.1.0
sc update etcd version=0.2.0
sc update auth-manager ....

I ran sc install right after getting the message "uninstalled service catalog successfully", and got the namespace AlreadyExists error:

maqiuyu-macbookpro:installer maqiuyu$ ./output/bin/sc uninstall
uninstalled service catalog successfully
maqiuyu-macbookpro:installer maqiuyu$ ./output/bin/sc install
generated service catalog deployment config in dir: /tmp/service-catalog625681308
Service Catalog could not be installed
Error: error deploying YAML files: deploy failed with output: exit status 1 :Error from server (AlreadyExists): error when creating "/tmp/service-catalog625681308/namespace.yaml": object is being deleted: namespaces "service-catalog" already exists

Seems that the deletion of "service-catalog" namespace takes a couple more seconds to finish after command completes.

We should make sure the namespace is actually gone before printing out the success message.

sc status command should be added to the commandline tool. sc status should display:

• if service catalog is installed or not
• Should display all the Service Catalog resources (like Deployments, Pods, Services etc.)

The main purpose of this command is to troubleshoot an installation. May be add a "debug" flag to the command which can start dumping the API Server/Controller logs.

It would be great to have a continuous test that runs the latest sc installer to create a GKE cluster and to install service catalog on it. Since both kubernetes and sc-installer keep being updated, it would be useful to notice the breakage as early as possible.