Description of problem:
no snapshot created when moveing snapshot to directory, user running jon does not have access to
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Schedule a take snapshot operation with Chose deletion strategy to move snapshots to a directory, user running jon does not have access to
Operation fails, no snapshot is created
Operation should fail with message telling, that it was not possible to move snapshots to 'no access' directory
New snapshot should be created under the default directory
I think this refers to the StorageNode takeSnapshot operation.
Does the failed operation have any information on what went wrong? I don't agree with the fact that we should create a snapshot to the default directory - since user it might run out of space (he didn't design it to be used this way for example), have I/O issues etc. and it's an unpredictable behaviour.
However, the failed operation (when clicking for more details) should include of course the information "No rights to write to the destination directory". I could not however replicate your behaviour, the take snapshot (in master) to /root/failme as normal user just got me operation success, while it should obviously fail (and no snapshot was put to the destination dir).
So I suggest dropping "default" idea (if you really want that - post-GA then, but not anymore in 3.3) and instead check that write to the destination really did succeed (I have nothing in my logs that would say it failed, so I have no idea what happened).
we've discussed on test-case review meeting with Larry .. and this BZ is outcome.
If user sets wrong (we're unable to write to it) directory to move snapshots to and he's ignoring alerts or failed operation statuses, the worst case that could happen is that he runs out of space.
If we do not take snapshot in such case at all, user (thinking he has setup which archives backup on regular basis) ignoring alerts or failed operation statuses could loose data - he expects some data to exist, but they don't.
The desired behavior is, generate snapshot and fail the operation with message "We was able to generate snapshot, although, we weren't able to move it to specified location"
I'll also rework the operation to fail same way in case we fail to delete some snapshots (this can easily happen on windows)
In fact, we'd need another state for operation result, something like SuccessWithWarnings.
That worse case of running out of diskspace on datanode is a serious one. It's a killer for any database, and _will_ result in a data loss. So I wouldn't take it as lightly and certainly wouldn't say "SuccessWithWarnings", but instead really keep it as "Failed", since that's the real outcome.
Michael .. I understand your arguments .. the only win win solution I can see now is adding another parameter that would specify how to behave if we cannot write to target dir (operation status would be failed), we'd either take the snapshot or not
Moving into ER05 as didn't make the ER04 cut.
time: 2014-10-10 15:52:23 +0200
author: Libor Zoubek - firstname.lastname@example.org
message: Bug 1141885 - no snapshot created when user does not have access to
takeSnaphost operation now always creates snapshot and then
checks for write permission on move location, which if not
granted, fails the entire operation) - operation also returns
string result saying major steps
(snapshot created, snapshots moved/deleted). Also operation now
fails in case we fail to delete or move any snapshot directory.
Moving to ON_QA as available to test with the latest brew build:
verified in JON 3.3 ER05
snapshot created, not moved to 'non-accessible' directory, full operation fails with message telling no write access.
Created attachment 949323 [details]