It might be a good idea to add a comment to the RPC layer for the snapshot call explaining why we haven't implemented a lock check. That would reduce future confusion as well.
Cheers, Michael On Fri, Jun 20, 2014 at 5:06 AM, melanie witt <melw...@outlook.com> wrote: > On Jun 17, 2014, at 13:34, Andrew Laski <andrew.la...@rackspace.com> wrote: > >> It appears that locking was added in 2010 >> (8aea573bd2e44e152fb4ef1627640bab1818dede), at which time commit messages >> weren't nearly as clear and helpful as they now are so there's not much >> insight from that. But the lock checking methods added at that time have a >> docstring that includes "decorator used for preventing action against locked >> instances". So the original intent seems to be that API actions would not >> be allowed against locked instances. From that point of view snapshotting >> should be disallowed. > > That's what I was going on initially too. I was ignorant about what locking > instances is really for and didn't find documentation about it other than > some anecdotal things in ML archive. > >> Having said that, the main reason that I've heard for locks being used is to >> prevent accidental deletes. And I've heard requests for locks that only >> prevent deletes. So in my experience users want more granular locks, not >> more inclusive locking. So I wouldn't consider it a bug that snapshots are >> allowed while an instance is locked. > > That's interesting and good to know. > >> But getting back to the original issue, I'm not sure locking snapshots is >> going to help. The intent seems to be keeping users from gaining access to >> data that's within the instance. But locks don't keep a user from seeing >> what's on the instance, or doing something like an LVM snapshot of the data >> from within the instance. > > That's true and underscores why locking as a security measure doesn't make > much sense. There are too many ways to get around it that you end up with a > quite incomplete lockdown. > > I think we have consensus that instance locking to protect content isn't an > appropriate use of the feature and anyway isn't a complete solution to that > problem. Instance locking prevents accidental changes/deletion of an instance > by way of the api. And in Michael's example scenario of having to unlock (and > risk accidental change/delete) in order to take a snapshot of an important > instance, disabling snapshot of a locked instance would actively disrupt the > expected use case of instance locking. > > Thanks all for the discussion -- I learned a lot about this feature and I'll > be updating the lp bug (not a bug) and review. > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
