search

kubernetes-retired / service-catalog

Consume services in Kubernetes using the Open Service Broker API
https://svc-cat.io
Apache License 2.0
1.05k stars 385 forks source link

"svcat provision --wait" should give an error if broker provision fails due to required/missing parameters #2425

Closed drnic closed 5 years ago

drnic commented 5 years ago

Bug Report

What happened:

I was trying out the GCP broker. Using svcat get classes and svcat get plans I discovered there was a single MySQL plan. I tried to provision it:

$ svcat provision mysql-db -n sb-demo --class cloud-sql-mysql --plan beta
  Name:        mysql-db
  Namespace:   sb-demo
  Status:
  Class:       cloud-sql-mysql
  Plan:        beta

Parameters:
  No parameters defined

$ svcat get instances
  NAME   NAMESPACE   CLASS   PLAN   STATUS
+------+-----------+-------+------+--------+

This was confusing as there were no errors above.

In the events I see:

$ kubectl describe -n sb-demo     serviceinstance.servicecatalog.k8s.io/mysql-db
...
  Type     Reason               Age   From                                Message
  ----     ------               ----  ----                                -------
  Warning  ProvisionCallFailed  31s   service-catalog-controller-manager  Provision call failed: operation "projects/491089609225/operations/1ef7f398-d351-11e8-b517-0a580a100221/1539920601545185004" failed: generic::invalid_argument: Operation "operation-1539920601855-5788cb474b419-2c72cbee-b51cc456" failed with
: [{"code":"MANIFEST_EXPANSION_USER_ERROR","location":"/deployments/i111bda58-7b99-47da-ac33-17d799c2fc26/manifests/manifest-1539920602078","message":"Manifest expansion encountered the following errors: Invalid properties for 'gcp-services/composite:cloud-sql-mysql-instance-f3622e2':\n'parameters' is a required property\n Resource: i111bda58-7b99-47da-ac33-17d799c2fc26 Resource: config"}]

I also tried svcat provision --wait but no error messages were displayed.

What you expected to happen:

I expected svcat provision to fail fast if there are require/missing/invalid parameters.

Environment:

Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-28T15:20:58Z", GoVersion:"go1.11", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.7-gke.6", GitCommit:"06898a4d0f2b96f82b43d9e59fa2825bd3d616a2", GitTreeState:"clean", BuildDate:"2018-10-02T17:32:01Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

latest helm chart

jboyd01 commented 5 years ago

I think you probably need to specify the namespace in the first $ svcat get instances command (ie the command returns no instances, I think if you specify the right namespace ( -n sb-demo) or --all-namespaces it will include your new instance). The output you got was using the default/current namespace and it appears there are no instances in it.

I think the svcat provision command is doing the right thing here - it's successfully queuing up a request to create an instance and then svcat terminates indicating it successfully asked for the instance to be created.

However, when you specify --wait, I'd expect svcat to tell you there was an error creating the instance.

I've updated the title of this issue to reflect these thoughts, please add comments if you don't agree with this change. Thanks for registering the issue!

drnic commented 5 years ago

I think the particular broker in question (google’s hosted broker) would benefit users if it failed fast before starting the asynchronous sequence (when it knows it will never succeed).

For async broker actions to relay in-progress messages, I think they need to mention something on https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#polling-last-operation-for-service-instances

Is svcat provision relying any status changes from this endpoint? Or is the google broker not providing any error status at this endpoint?

From: Jay Boyd notifications@github.com Sent: Tuesday, October 23, 2018 4:54 am To: kubernetes-incubator/service-catalog Cc: Dr Nic Williams; Author Subject: Re: [kubernetes-incubator/service-catalog] "svcat provision --wait" should give an error if broker provision fails due to required/missing parameters (#2425)

I think you probably need to specify the namespace in the first $ svcat get instances command (ie the command returns no instances, I think if you specify the right namespace ( -n sb-demo) or --all-namespaces it will include your new instance). The output you got was using the default/current namespace and it appears there are no instances in it.

I think the svcat provision command is doing the right thing here - it's successfully queuing up a request to create an instance and then svcat terminates indicating it successfully asked for the instance to be created.

However, when you specify --wait, I'd expect svcat to tell you there was an error creating the instance.

I've updated the title of this issue to reflect these thoughts, please add comments if you don't agree with this change. Thanks for registering the issue!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/kubernetes-incubator/service-catalog/issues/2425#issuecomment-431935786, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAAbKi4QUQGFD8AeAgyNJU95nxcjXjeks5unhRpgaJpZM4Xvn3Q.

jboyd01 commented 5 years ago

cc @kibbles-n-bytes , @n3wscott see above re google's hosted broker

fejta-bot commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 5 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

fejta-bot commented 5 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

k8s-ci-robot commented 5 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/service-catalog/issues/2425#issuecomment-505413257): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.