Open Stack

After thinking about this some more, I think a simple implementation
disable_terminate is still a valid ask.

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.

disable_terminate would protect from accidental deletion of the VMs, but
they would still be able to be rebooted, etc. via the API.

Thoughts?

-AH


On Tue, May 7, 2013 at 5:38 PM, John Garbutt <john at johngarbutt.com> wrote:

> Probably stating the obvious, but I could imagine extending the who to
> be a role.
>
> You can then define some kind of (linear) precedence order among
> roles. Ensure peers can't unlock each other, but supervisors can
> unlock any lower lock.
> But allowing all top level people to unlock each other.
>
> That way it can default to (user > admin), giving mandatory-vm-lock
> behaviour.
> But you could change it to (user > tenant_admin > support_a =
> support_b > super_admin)
>
> Although that feels a bit over complicated,
> John
>
> On 6 May 2013 18:16, Russell Bryant <rbryant at redhat.com> wrote:
> > On 05/06/2013 12:03 PM, Andy Hill wrote:
> >> Greetings,
> >>
> >> I wanted to open a discussion on how Nova can prevent users and
> >> administrators from accidental instance deletion.
> >>
> >>
> https://blueprints.launchpad.net/nova/+spec/ability-to-set-disable-terminate
> >>
> >> Russell brought up a good point on this blueprint that there's already
> >> 'nova lock', but it looks like a locked instance can still be deleted by
> >> an administrator.
> >>
> >> Compute's API already implements disable_terminate, but there's no way
> >> to set it via Nova API.
> >>
> >> https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1038
> >>
> >> There could be two ways to go about implementing disable_terminate:
> >>
> >> - nova lock <uuid> --disable_terminate could set disable_terminate on
> >> the instance (admin only)
> >> - nova disable_terminate <uuid>
> >
> > There was another patch that didn't get finished to keep track of *who*
> > locked an instance (user or admin).  If an admin locked an instance,
> > then the user would not be able to unlock it.
> >
> > How about finishing that, and then making sure that if an admin locks an
> > instance, it can't be deleted?
> >
> > https://blueprints.launchpad.net/nova/+spec/mandatory-vm-lock
> >
> > https://review.openstack.org/#/c/21535/
> >
> > Other than an instance being administratively locked, I don't think it
> > makes sense to ever prevent an *admin* from deleting an instance.  It's
> > like having root ... use it with care.  :-)
> >
> > --
> > Russell Bryant
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andy Hill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130604/60863ea1/attachment.html>