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): JON 3.3 How reproducible: 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 2. 3. Actual results: Operation fails, no snapshot is created Expected results: 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 Additional info:
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).
Michael, 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.
branch: master link: https://github.com/rhq-project/rhq/commit/882ac0dc0 time: 2014-10-10 15:52:23 +0200 commit: 882ac0dc037a16b958d713ad58cd0d3ecca8b89c author: Libor Zoubek - lzoubek message: Bug 1141885 - no snapshot created when user does not have access to directory 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: https://brewweb.devel.redhat.com//buildinfo?buildID=394734
verified in JON 3.3 ER05 snapshot created, not moved to 'non-accessible' directory, full operation fails with message telling no write access. screen-shots attached
Created attachment 949323 [details] no_access_operation