Remove applied test case in update operation

[leonwanghui]

Generally this patch will remove Update - applied test case in testUpdate.js with reasons below:

• For most platforms (k8s or openshift), they will lock any operation of that instance if async operation is not finished, so normally users can't perform the update request twice manually through the platform
• Even if users can perform the update request twice (the second one comes after the first one finished), broker can also return 202 and then the platform trigger lastOperation
• If the second one comes before the first one finished, according to the 2.13 sepc, the broker should return 202 rather than 200.

So it's better to keep the broker return 202 for all three scenarios before, and therefore the applied test should be removed.

[cfdreddbot]

:white_check_mark: Hey leonwanghui! The commit authors and yourself have already signed the CLA.

[zhongyi-zhang]

Sorry, I still didn't get your point... Isn't the case removed in the situation that the last update operation is already done after polling https://github.com/openservicebrokerapi/osb-checker/blob/master/common/testUpdate.js#L95-L102?

[leonwanghui]

Hi @mattmcneeney @duglin , we are gonna need your help, thanks!

[norshtein]

The question is: unlike provisioning response can have 200, 201, 202 status code, the updating response can only have 200 and 202 status code. Consider following scenarios:

• Provisioning
  • 1. The service broker receives an async provisioning request, it returns 202
    2. After some time, the provisioning operation completes.
    3. The service broker receives an async provisioning request having the same parameters as in step a, so it returns 200
  • 1. The service broker receives a sync provisioning request, after some time, the provisioning operation successes, and it returns 201
• Updating
  • 1. The service broker receives an async updating request, it returns 202
    2. After some time, the updating operation completes.
    3. The service broker receives an async updating request having the same parameters as in step a, what status code should the service broker return?
  • 1. The service broker receives a sync updating request, after some time, the updating operation successes, what status code should the service broker return?

[zhongyi-zhang]

For async update, it should definitely return 200. For sync update, I think it should return 200, too. In sync update, there is no difference between "a brand new update request" and "a update request which it is already applied". Code 200 just indicates that the operation is done.

[mattmcneeney]

Hey @leonwanghui Do we have a test case for a synchronous update returning a 200 (with accepts_incomplete=false)? Since this is really what is being tested for with expecting a 200 straight away

[leonwanghui]

Yes, please see here

[mattmcneeney]

Great, I think this is fine then!