update: Allow cancellation of an update in completing state

[detsch]

Updates might get stuck in the "completing" state if we hit an error inside runnerImpl.complete. The user can't currently recover from this.

[mike-sul]

This will allow users to "cancel" an update that has been successfully started, as a result successful update is considered as "failing".

Maybe we rather should fix the "composectl update complete" implementation, so it guarantees moving the update state to the "completed" as long as the update is successfully started.

[mike-sul]

Updates might get stuck in the "completing" state if we hit an error
inside runnerImpl.complete. The user can't currently recover from this.

According to this

composeapp/pkg/update/update.go

Line 423 in 007dc4b

u.State = StateFailed

the update state is moved to the "failed" if an error occurs during running complete, so it is not quite clear how/why a user can get stuck at the "completing" state.

[detsch]

Updates might get stuck in the "completing" state if we hit an error
inside runnerImpl.complete. The user can't currently recover from this.

According to this

composeapp/pkg/update/update.go

Line 423 in 007dc4b

u.State = StateFailed

the update state is moved to the "failed" if an error occurs during running complete, so it is not quite clear how/why a user can get stuck at the "completing" state.

What about the errors.Is(err, compose.ErrUninstallRunningApps) case?

I was hitting the situation of having a update stuck in completing state with some early testing code, I can try to reproduce it again if necessary. But if I'm not mistaken, it was a situation where there were leftover apps that were not stopped and could not be uninstalled.

What if the process gets killed before the we have the chance of setting u.State = StateFailed? Not likely, but we do need some way of recover from such situation. I was experiencing a situation that could not be recovered by just calling fioup commands.

[mike-sul]

What if the process gets killed before the we have the chance of setting u.State = StateFailed?

The update will be in "completing" state and the next attempt will "complete" it.

[mike-sul]

What about the errors.Is(err, compose.ErrUninstallRunningApps) case?

That's the case when complete is invoked with pruning and the latter fails because of some uninstall or remove failures.

I think a client should do a few update complete --prune attempts, and then if keeps failing then just run update complete (no pruning) to complete the update.

It looks like we need to adjust fioup implementation to handle ErrUninstallRunningApps.

The key question is: Should we consider an update successful if all update apps were pulled, installed, and started successfully while the pruning failed or not?

[detsch]

The key question is: Should we consider an update successful if all update apps were pulled, installed, and started successfully while the pruning failed or not?

I think that is fine. It is OK to consider it successful.

[mike-sul]

The key question is: Should we consider an update successful if all update apps were pulled, installed, and started successfully while the pruning failed or not?

I think that is fine. It is OK to consider it successful.

If so, then we cannot use cancel as it marks an update as "canceled" not as "completed" (ok).
I rather suggest to improve the "Complete" API call and allow doing enforced completion of successfully started update.

[detsch]

Closed in favor of #105 and foundriesio/fioup#147