openstack team mailing list archive

[Blake Yeager <blake.yeager@xxxxxxxxxxxxx>]

Looking at it from a service provider point of view I think there are two separate reasons to lock the state of an instance.

First is the issue of a legal violation on behalf of the customer.  Either they have not paid their bill and are in violation of their contract or they have been using the resource to perform illegal activity or activity that is expressly prohibited in the the a service provider's Acceptable Use Policy.  In this case the service provider needs to be able to shut down the instance and  prevent the customer from deleting the instance or restarting it.  (Deleting it could erase data that the service provider is legally required to maintain in the case of illegal activity.)  This action should only be preformed via the admin API and needs to be executable regardless of the state of the instance or any "state_lock" field.

The second use case is where a customer may want to lock an instance to prevent themselves from accidentally deleting it or shutting it down via the API.  This would prevent a broken script or program from running away and deleting important servers in a customer's account.  They would probably enable this lock on instances that contained critical infrastructure that they were expecting to keep running for a long time or didn't want to be accidentally deleted.  I could even envision an extreme setup where a customer is not able to take a server out of this locked state without interacting with the service providers support team who could unlock it via the admin API.  Even when this lock is in place the service provider needs to be able to override this lock and shutdown and "boot_lock" the instance in the case of a legal violation mentioned above.

I don't have much of an opinion as to whether it should be implement using the boot_lock inside the hypervisor or in the Nova code but I think it should be able to support both the use cases above.

-Blake


From: Matt Dietz <matt.dietz@xxxxxxxxxxxxx<mailto:matt.dietz@xxxxxxxxxxxxx>>
Date: Tue, 14 Dec 2010 22:10:48 +0000
To: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Suspend and locking instances

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<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