On Thu, Mar 1, 2018 at 9:21 AM Max Cuttins <max@xxxxxxxxxxxxx> wrote:
I think this is a good question for everybody: How hard should be delete a Pool?
We ask to tell the pool twice.
We ask to add "--yes-i-really-really-mean-it"
We ask to add ability to mons to delete the pool (and remove this ability ASAP after).
... and then somebody of course ask us to restore the pool.
I think that all this stuff is not looking in the right direction.
It's not the administrator that need to be warned from delete datas.
It's the data owner that should be warned (which most of the time give it's approval by phone and gone).
So, all this stuff just make the life of administrator harder, while not improving in any way the life of the Data Owner.
Probably the best solution is to ...do not delete at all and instead apply a "deleting policy".
Something like:
ceph osd pool rm POOL_NAME -yes
-> POOL_NAME is set to be deleted, removal is scheduled within 30 days.
This allow us to do 2 things:
- allow administrator to don't waste their time in CML with true strange command
- allow data owner to have a grace period to verify if, after deletion, everything works as expected and that data that disapper wasn't usefull in some way.
After 30 days data will be removed automatically. This is a safe policy for ADMIN and DATA OWNER.
Of course ADMIN should be allowed to remove POOL scheduleded for deletion in order to save disk spaces if needed (but only if needed).What do you think?
You're not wrong, and indeed that's why I pushed back on the latest attempt to make deleting pools even more cumbersome.
But having a "trash" concept is also pretty weird. If admins can override it to just immediately delete the data (if they need the space), how is that different from just being another hoop to jump through? If we want to give the data owners a chance to undo, how do we identify and notify *them* rather than the admin running the command? But if admins can't override the trash and delete immediately, what do we do for things like testing and proofs of concept where large-scale data creates and deletes are to be expected?
-Greg
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
