openstack team mailing list archive

[Trey Morris <trey.morris@xxxxxxxxxxxxx>]

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 <blake.yeager@xxxxxxxxxxxxx>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 <matt.dietz@xxxxxxxxxxxxx>
> Date: Tue, 14 Dec 2010 22:10:48 +0000
> To: "openstack@xxxxxxxxxxxxxxxxxxx" <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>
> Date: Tue, 14 Dec 2010 15:04:17 -0600
> To: <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, and delete the original message.
> Your cooperation is appreciated.
>
> _______________________________________________ Mailing list:
> https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netUnsubscribe :
> 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.
>
>  _______________________________________________ Mailing list:
> https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netUnsubscribe :
> https://launchpad.net/~openstack More help :
> https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>