You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug happens when there's a failure when deploying resource into its service provider, such as bigquery. The steps below should explain better about this case.
To Reproduce
Steps to reproduce the behavior:
create a valid resource, such as view. however, make sure that the resource will be failed when storing to the service provider, like bigquery. for example like access.
deploy to optimus the newly created resource. in this state, optimus should fail the deployment process to the service provider. however, the resource itself is already stored in the database.
don't update the resource spec, just update the access for it to pass the service provider
re-deploy through optimus. and in this step, optimus shouldn't fail. however, optimus will skip deployment process, meaning the resource is not created.
The reason for the result of the steps above is because in Optimus, we have a mechanism to skip resource if there is no difference between the incoming one and the one in database.
Expected behavior
Resource should be stored in database, and deployed to the targetted service provider.
The text was updated successfully, but these errors were encountered:
@irainia@sravankorumilli the problem of this issue is because there's a lack of atomicity property in our create / update resource system. Atomicity means all or nothing. In this case, there're 2 main operation in create / update resource (in sequential order):
save the resource spec to DB
actual table creation / modification on service provider
When atomicity property is not provided, for example, whenever access on service provider is problematic, only the first operation is getting executed and the second operation is not being executed. It leads to inconsistency between both operations. We need a mechanism where if one operation is failing, then all operations is not executed.
So far the approach we can take is rolling back when one operation is failing. eg, when creation / modification on service provider is failing, then, resource spec in DB should be rolled back to the previous state.
Describe the bug
This bug happens when there's a failure when deploying resource into its service provider, such as bigquery. The steps below should explain better about this case.
To Reproduce
Steps to reproduce the behavior:
The reason for the result of the steps above is because in Optimus, we have a mechanism to skip resource if there is no difference between the incoming one and the one in database.
Expected behavior
Resource should be stored in database, and deployed to the targetted service provider.
The text was updated successfully, but these errors were encountered: