Prevent execution of scheduled service operation
Closed this issue · 3 comments
From @pujarisat
This issue is reported with service operations in a custom VM controller implementation.
[Build and version]
17.3.1
“When User tries to Start VM which is already started then it shows the proper message (VM is already started) in the UI and API however when we modify the same subscription after completing the modification call it automatically trigger the start operation(Last interrupted operation)”
[procedure]
- User has subscribed a service based on custom VM Controller implementation
- User schedules operation O from subscription UI to start VM on subscription X which is already
started - Custom controller throws an exception “VM is already started” with respective message displayed in
Subscription details - User modifies subscription X, which completes successfully to active state
- Same operation O is automatically triggered again
Claim is that start operation is trigged automatic through OSCM.
Q: How to ensure operation abort properly?
The asynchronous operations are queued in APP. APP provides a retry handling for failed operations. In case the implementing platform controller throws an exception within the operation service the executed operation is pushed back to the queue and retried in same transaction as soon as provisioning instance is available .
This is what is observed after modifying the VMWare controller subscription and it's working as designed.
OSCM marketplace UI provides are process view, which list all running operations. The operation progress and result is reflect there. The subscription UI is not designed for such feedback.
As workaround the operation service should be implemented to filter the repeated invocations from queue.
@kowalczyka
Please share the details and advise how to implement it.
To overcome the issue described above controller should filter out the operation which is trying to be reexecuted (after previous failure - in this case VMWare already started).
To do this, when operation is executed for the first time it must be stored somehow (transactionId can be used) on the failure case (e.g. singleton class containing those transaction ids). When it is trying to be reexecuted (the same transactionId is coming), it should be filtered out and operation execution should be interrupted.
Other way to check reexecuting operation would be to use app db. Operation table contains those failed operations so they can be compared with current one (which can be the prevent from being executed)
The solution has been proposed as above. I close this incident, because there is no further activity. If there is any issue remaining let us know.