-
Notifications
You must be signed in to change notification settings - Fork 40
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
destroy both VMMs from the update saga
As per [this comment][1] from @gjcolombo, we've determined that the update saga *should* be responsible for cleaning up sled resource allocations if handling an update where the active *or* target VMM has been `Destroyed`. This commit updates the saga to do that, turning the destroyed VMM cleanup actions into a subsaga so that we can, potentially, perform it for both VMMs. Releasing sled resources and marking VMMs as deleted is performed after the saga has written back the instance record with both VMMs unlinked, and dropped the lock. This ensures we don't leave "dangling pointers" in the instance record, by having a foreign key into the VMM table for a VMM that no longer exists. Since writing back the instance record releases the lock, this means that cleaning up resource allocations happens outside the lock. This way, sled resources are deallocated immediately, to prevent sled resource exhaustion from rapidly churning failed migrations, but we also release the update lock so that another update saga can start. Resources owned by the *instance* --- the oximeter producer and virtual provisioning resources --- are deallocated within the lock if and only if the instance has no active VMM. VMMs are cleaned up when they are destroyed regardless of whether the instance has an active VMM (e.g. destroyed targets are deleted when a migration fails, and destroyed source VMMs are deleted when a migration succeeds, but the instance's virtual resources are not deallocated in either case). [1]: #5749 (comment)
- Loading branch information
Showing
3 changed files
with
285 additions
and
180 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.