Open mattmcneeney opened 4 years ago
Hi Matt,
in our pipelines the test is green. I will double check it with the checkers code. But our service brokers send a 409 there.
Interesting. I wonder if this is to do with the application.yml
? I don't specify any services/plans because I expect the full catalog to be used:
##Define the service broker connection here
config:
url: http://localhost
port : 3000
apiVersion: 2.15
user: admin
password: password
This is the broker I'm using in case you want to have a go: https://github.com/cloudfoundry/overview-broker
Hi Matt, Thanks for raising this. My logs are wrong here. It's not swapping the plan_id, but the space_guid and org_guid, as this was the simpler solution to force a conflict statusCode in compliance with the spec. This means your Service Broker is not checking if these fields are correct.
Only for bindings, the plan_id is changed, if there are multiple plans defined inside the catalog because there are no other mandatory fields than service_id and plan_id. When implementing this, I must have broken the logs. Sorry about that.
@chbrinker We could add checks that verify a 409 with different plan_id and the other fields each. Any thoughts?
Ah good spot!
You're right that my broker doesn't check these fields. I can add a check, but given that the organization_guid
and space_guid
fields are deprecated, it might be worth changing this test to change the service_id
or plan_id
field.
I think it would be better to make this API-version dependent feature since these fields are still considered mandatory.
When running the
-binding
test suite, the following test is failing:However, when I check the logs for the broker, I can see that the three corresponding provision requests:
However, the third provision request is supposed to contain a different
plan_id
, and hence the test expects a409
status code. It seems like the broker is receiving the sameplan_id
on all three requests, and hence returns a200
status code.Could you check whether this is a bug in the test suite for me?