openstack team mailing list archive

[Matt Dietz <matt.dietz@xxxxxxxxxxxxx>]

Trey and I were discussing this earlier, and the suggestion below is what we came up with.

Regarding the boot lock functionality, this is a feature that Rackspace specifically requires. However, we don't want to implement it in a way that's restrictive or business specific, so we're proposing the idea of the state lock instead. As I understand it, a similar feature has been requested that basically prevents any actions from accidentally taking place against a given instance.

The idea would be to add an extra field to the Instance model that's a simple boolean, and said boolean could be checked by any code attempting to change state. This leads into a secondary discussion of possible state machine implementations. I'd prefer to not force anyone implementing a new instance action to handle the state_lock field manually, as it would probably result in the same 3 or 4 lines of code copy-pasted everywhere. However, I'm largely unaware of what the "good" solutions are to this problem. My knee-jerk answer is a decorator for state changing methods with set of "black-list" states that are automatically rejected by the decorator.

From: Trey Morris <trey.morris@xxxxxxxxxxxxx<mailto:trey.morris@xxxxxxxxxxxxx>>
Date: Tue, 14 Dec 2010 15:04:17 -0600
To: <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: [Openstack] Suspend and locking instances

Regarding https://blueprints.launchpad.net/nova/+spec/xs-suspend

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/comments on the general state lock idea vs hypervisor boot lock vs implementing instance locking at all within nova, as well as ideas for a clean implementation of a state lock if the idea is agreeable.

-tr3

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx<mailto:abuse@xxxxxxxxxxxxx>, and delete the original message.
Your cooperation is appreciated.


_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.