Lock an instance from reboot if suspended.
Lock an instance so it does not start back up even if the user sends a reboot signal to the host.
The instance would then be in a suspended and locked state.
Blueprint information
- Status:
- Complete
- Approver:
- Rick Clark
- Priority:
- Low
- Drafter:
- Paul Voccio
- Direction:
- Needs approval
- Assignee:
- Trey Morris
- Definition:
- Approved
- Series goal:
- Accepted for bexar
- Implementation:
- Implemented
- Milestone target:
- None
- Started by
- Sandy Walsh
- Completed by
- Thierry Carrez
Whiteboard
Thoughts on the locking portion:
We need suspend as a power state (ram goes to disk, instance is shut down) as well as a locking suspend (ram goes to disk, instance is shut down, instance is no longer customer bootable) which make sense from a billing point of view. The issue is where this lock is going to be. For example, in Xenserver we can set whether an instance is bootable, but I'm unsure if this feature is supported in other hypervisors. Even if it were supported across the hypervisor board this would be a specific case of lock (locking the instance in a shutdown/suspend type state). Instead, I propose a state lock. When an instance is state locked, no functions which enact a change in state may be executed. State lock would be above the hypervisor level and require storage in a table. Being above the hypervisor level gives us the advantage of not having to implement boot lock functionality in each hypervisor api and we get a more general lock feature which can be used in more situations. I don't like the idea of all the compute worker functions having to check for state lock status because it's ugly as well as code duplication, but I'm not sure of a better way at the moment.
I'm looking for suggestions/
Current Proposal:
db/logical lock, I dislike the idea of a vm lock. Shouldn't have to code around mistakes ops could make and I also have more faith in ops. Hypervisors should be configured to reboot or start up without rebooting/
To sum up: nothing but the compute worker should be changing the state of instances on the hypervisor. If something else manages to do so, the compute worker should be able to handle that situation gracefully.