<div dir="ltr"><div>After thinking about this some more, I think a simple implementation disable_terminate is still a valid ask.<br><br></div>Using lock prevents all other actions from being taken on a server. An example case where disable_terminate vs. lock is preferable is for a HA pair of VMs using Nova API for STONITH purposes. <br>
<br>disable_terminate would protect from accidental deletion of the VMs, but they would still be able to be rebooted, etc. via the API.<br><div><br></div><div>Thoughts?<br><br></div><div>-AH</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, May 7, 2013 at 5:38 PM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Probably stating the obvious, but I could imagine extending the who to<br>
be a role.<br>
<br>
You can then define some kind of (linear) precedence order among<br>
roles. Ensure peers can't unlock each other, but supervisors can<br>
unlock any lower lock.<br>
But allowing all top level people to unlock each other.<br>
<br>
That way it can default to (user > admin), giving mandatory-vm-lock behaviour.<br>
But you could change it to (user > tenant_admin > support_a =<br>
support_b > super_admin)<br>
<br>
Although that feels a bit over complicated,<br>
John<br>
<div class="HOEnZb"><div class="h5"><br>
On 6 May 2013 18:16, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
> On 05/06/2013 12:03 PM, Andy Hill wrote:<br>
>> Greetings,<br>
>><br>
>> I wanted to open a discussion on how Nova can prevent users and<br>
>> administrators from accidental instance deletion.<br>
>><br>
>> <a href="https://blueprints.launchpad.net/nova/+spec/ability-to-set-disable-terminate" target="_blank">https://blueprints.launchpad.net/nova/+spec/ability-to-set-disable-terminate</a><br>
>><br>
>> Russell brought up a good point on this blueprint that there's already<br>
>> 'nova lock', but it looks like a locked instance can still be deleted by<br>
>> an administrator.<br>
>><br>
>> Compute's API already implements disable_terminate, but there's no way<br>
>> to set it via Nova API.<br>
>><br>
>> <a href="https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1038" target="_blank">https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1038</a><br>
>><br>
>> There could be two ways to go about implementing disable_terminate:<br>
>><br>
>> - nova lock <uuid> --disable_terminate could set disable_terminate on<br>
>> the instance (admin only)<br>
>> - nova disable_terminate <uuid><br>
><br>
> There was another patch that didn't get finished to keep track of *who*<br>
> locked an instance (user or admin).  If an admin locked an instance,<br>
> then the user would not be able to unlock it.<br>
><br>
> How about finishing that, and then making sure that if an admin locks an<br>
> instance, it can't be deleted?<br>
><br>
> <a href="https://blueprints.launchpad.net/nova/+spec/mandatory-vm-lock" target="_blank">https://blueprints.launchpad.net/nova/+spec/mandatory-vm-lock</a><br>
><br>
> <a href="https://review.openstack.org/#/c/21535/" target="_blank">https://review.openstack.org/#/c/21535/</a><br>
><br>
> Other than an instance being administratively locked, I don't think it<br>
> makes sense to ever prevent an *admin* from deleting an instance.  It's<br>
> like having root ... use it with care.  :-)<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Andy Hill
</div>