I wonder if this bp should be split into two topics: 1. instance locking 2. instance suspend
I think they merit a split. -Sandy ________________________________ From: [email protected] [[email protected]] on behalf of Trey Morris [[email protected]] Sent: Wednesday, December 15, 2010 12:54 PM To: Blake Yeager Cc: [email protected] Subject: Re: [Openstack] Suspend and locking instances Having a state lock in the admin api will perform both of these tasks, there is no reason to have both a state lock and hypervisor boot lock. Your first issue is solved by first locking the customer's instance(s), then setting the state to whatever you wish (shutdown, suspend, pause, etc). Once locked the customer has no ability to unlock or perform actions, only the admin api will be able to perform these actions. Locked instances will be under the full control of the service provider. I'm not sure of the best way to implement a solution to your second issue. If locking is an admin task, customers would never be able to set or unset locks on their instances. Your extreme case doesn't seem so extreme to me. Customers generally always have to contact support when in need of admin tasks; as an admin task locks would be no different. It would then fall to the service provider to determine how to implement locks within their support structure or how not to. -tr3 On Tue, Dec 14, 2010 at 6:54 PM, Blake Yeager <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> Date: Tue, 14 Dec 2010 22:10:48 +0000 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Date: Tue, 14 Dec 2010 15:04:17 -0600 To: <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
