Bug 1141885 - no snapshot created when user does not have access to directory
Summary: no snapshot created when user does not have access to directory
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Operations
Version: JON 3.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER05
: JON 3.3.0
Assignee: Libor Zoubek
QA Contact: Armine Hovsepyan
Depends On: 1074633
TreeView+ depends on / blocked
Reported: 2014-09-15 16:12 UTC by Armine Hovsepyan
Modified: 2015-11-02 00:44 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2014-12-11 13:59:36 UTC

Attachments (Terms of Use)
no_access_operation (172.75 KB, image/png)
2014-10-22 09:46 UTC, Armine Hovsepyan
no flags Details

Description Armine Hovsepyan 2014-09-15 16:12:52 UTC
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

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:

Comment 1 Jay Shaughnessy 2014-09-15 17:33:34 UTC
I think this refers to the StorageNode takeSnapshot operation.

Comment 2 Michael Burman 2014-09-16 20:09:02 UTC
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).

Comment 3 Libor Zoubek 2014-09-16 21:12:43 UTC

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.

Comment 4 Michael Burman 2014-09-17 06:00:45 UTC
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.

Comment 6 Libor Zoubek 2014-09-17 10:18:59 UTC
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

Comment 9 Simeon Pinder 2014-09-29 08:12:47 UTC
Moving into ER05 as didn't make the ER04 cut.

Comment 10 Libor Zoubek 2014-10-10 13:52:49 UTC
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@redhat.com
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.

Comment 12 Simeon Pinder 2014-10-21 20:24:23 UTC
Moving to ON_QA as available to test with the latest brew build:

Comment 13 Armine Hovsepyan 2014-10-22 09:45:15 UTC
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

Comment 14 Armine Hovsepyan 2014-10-22 09:46:20 UTC
Created attachment 949323 [details]

Note You need to log in before you can comment on or make changes to this bug.