Description of problem:
When describe a ready serviceinstance,there are some error shown.
Version-Release number of selected component (if applicable):
brew-*/ose-service-catalog v3.7.0-0.185.0.0 ef0dd815574a 2 days ago 266 MB
Steps to Reproduce:
1.Privision mariadb-ephemeral clusterserviceclass in browse catalog
2.Describe serviceinstance after it's ready
oc describe serviceinstance -n myproject
1h 1h 3 service-catalog-controller-manager Warning ErrorWithParameters Failed to prepare ServiceInstance parameters nil: secrets "mariadb-ephemeral-parametersi0l6n" not found
1h 1h 1 service-catalog-controller-manager Normal Provisioning The instance is being provisioned asynchronously
1h 1h 1 service-catalog-controller-manager Warning ProvisionCallFailed Error provisioning ServiceInstance of ClusterServiceClass (K8S: "7d08ff2c-bd1f-11e7-a6c2-fa163e5abcb3" ExternalName: "mariadb-ephemeral") at ClusterServiceBroker "template-service-broker": Status: 409; ErrorMessage: <nil>; Description: <nil>; ResponseError: <nil>
1h 1h 1 service-catalog-controller-manager Normal ProvisionedSuccessfully The instance was provisioned successfully
Should no error shown.
The first warning is due to the ServiceInstance being created prior to the Secret. The service catalog controller tries to reconcile the new ServiceInstance a few times before the Secret exists.
The second warning is due to a bug in service catalog that has the controller sending multiple duplicate requests to the broker. The warning is for the second Provision request, which is rejected by the broker due to its being a duplicate of an on-going Provision request. This bug is being tracked upstream by https://github.com/kubernetes-incubator/service-catalog/issues/1363.
Jay, will you please determine if this is still an issue?
Still an issue in some circumstances. Upstream issue is still open.
Still an issue, please note these are basically noise, but I do agree its a bug and can be misleading/alarming.
tracked by two upstream issues:
This is actually working as designed from standpoint of events. Events generated for a particular resource have a TTL and stay around until that TTL elapses. So, it's correct that you should see them in this case.
It is useful to note when we do see events that indicate errors that there may be other problems. Since this bug is rather old at this point, I would like QE to retest with the knowledge that it is correct that old events should stay around even after problem conditions are resolved.
The error messages have updated, one item about "ClusterServiceBrokerReturnedFailure " is added.
Should we update the <nil> in "Status: 409; ErrorMessage: <nil>; Description: <nil>; ResponseError: <nil>" with detailed
Warning ErrorWithParameters 3m service-catalog-controller-manager failed to prepare parameters nil: secrets "mysql-ephemeral-parameters4alxx" not found
Normal Provisioning 3m service-catalog-controller-manager The instance is being provisioned asynchronously
Warning ProvisionCallFailed 3m service-catalog-controller-manager Error provisioning ServiceInstance of ClusterServiceClass (K8S: "5028e5a5-1776-11e8-b8ae-fa163e82662b" ExternalName: "mysql-ephemeral") at ClusterServiceBroker "template-service-broker": Status: 409; ErrorMessage: <nil>; Description: <nil>; ResponseError: <nil>
Warning ClusterServiceBrokerReturnedFailure 3m service-catalog-controller-manager Error provisioning ServiceInstance of ClusterServiceClass (K8S: "5028e5a5-1776-11e8-b8ae-fa163e82662b" ExternalName: "mysql-ephemeral") at ClusterServiceBroker "template-service-broker": Status: 409; ErrorMessage: <nil>; Description: <nil>; ResponseError: <nil>
Normal ProvisionedSuccessfully 2m service-catalog-controller-manager The instance was provisioned successfully
the HTTP 409 is caused by https://github.com/kubernetes-incubator/service-catalog/issues/1639 (duplicate provision requests). The error details (ErrorMessage and Description) are optional details that may be set by the Broker.
You might consider filing an issue against it.
Thanks, reported a bug for issue in comment #10
As comment #8, move this bug as verified.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.