Closed technosophos closed 4 years ago
The second half of that comment is relevant, but more to how Duffle should work:
Right now duffle is only handling the returned error from an action's execution and then updating the claim. There are edge cases where the claim may never be updated even though an action was executed to some point of failure, for instance the power went out, code panic, CTRL+C caused tool to quit immediately, acts of godzilla, etc. I can see having some record of the attempt being useful. That way we at least know that resources are in an uncertain state, and the bundle needs to be retried/cleaned up.
This issue seems to have been addressed when status: underway
was added.
I know there is still debate going on in #309 about what is meant by underway
, but it sounds to me like the issue is that when a claims store is shared across multiple runtimes, the assumption is that a claim will exist, and that the claim will somehow serve as a lock or state file. I think that is possible with status: underway
... though claims were really intended to be records of finished operations, not in-flight operations.
From @carolynvs #251:
Providing a way to indicate on a claim that an action has begun. Consider the prototype CNAB Dashboard I showed a while back. If we updated the claim when an action has started, you could know which bundles are being currently executed, and which action. Right now claims are stored on the local file system so it may not make sense, but if you think about in the future when teams may have claims persisted in a common location, and are reporting off of that claim store... That's where this would be useful. https://github.com/cnabio/cnab-spec/issues/251#issuecomment-529001842