Bug 1771606

Summary: Exception in log on permission denied when trying to schedule a backup to NFS
Product: Red Hat CloudForms Management Engine Reporter: Jaroslav Henner <jhenner>
Component: User ExperienceAssignee: Tereza Novotna <tnovotna>
Status: CLOSED WONTFIX QA Contact: Sudhir Mallamprabhakara <smallamp>
Severity: low Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: low    
Version: 5.10.11CC: abellott, bmidwood, dmetzger, obarenbo, yrudman
Target Milestone: GA   
Target Release: 5.11.z   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-15 19:31:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:

Description Jaroslav Henner 2019-11-12 16:42:23 UTC
Created attachment 1635432 [details]
evm.log

Description of problem:
when scheduling a backup to a NFS mountpoint with permissions that doesn't allow CFME to store the file, I get an exception in log.

I am not sure what is the expected behaviour -- if we should get just an error or if we want an exception with traceback. Most of the time I personally like to get traceback as it is then easier to find the problem.


Version-Release number of selected component (if applicable):
Version 5.11.1.0.20191105221526_f1764d4

How reproducible:
1/1


Steps to Reproduce:
1. Have a directory exported with NFS:
 drwxr-xr-x. 3 root root 1024 Nov 12 11:24 /srv/export/db_backup/littlespacedir
2. Schedule a backup to that
3.


Actual results:
[----] I, [2019-11-12T11:30:17.875383 #7236:2ad6a36725c4]  INFO -- : MIQ(Class-disconnect) Disconnecting mount point: /tmp/miq_20191112-7236-4gmw3x...Complete
[----] E, [2019-11-12T11:30:17.875913 #7236:2ad6a36725c4] ERROR -- : MIQ(MiqQueue#deliver) Message id: [1225], Error: [Permission denied @ dir_s_mkdir - nfs://X.Y.Z.A/srv/export/db_backup/littlespacedir/region_0]
[----] E, [2019-11-12T11:30:17.876196 #7236:2ad6a36725c4] ERROR -- : [Errno::EACCES]: Permission denied @ dir_s_mkdir - nfs://X.Y.Z.A/srv/export/db_backup/littlespacedir/region_0  Method:[block (2 levels) in <class:LogProxy>]
[----] E, [2019-11-12T11:30:17.876387 #7236:2ad6a36725c4] ERROR -- : /usr/share/ruby/fileutils.rb:232:in `mkdir'
/usr/share/ruby/fileutils.rb:232:in `fu_mkdir'
/usr/share/ruby/fileutils.rb:210:in `block (2 levels) in mkdir_p'
/usr/share/ruby/fileutils.rb:208:in `reverse_each'
/usr/share/ruby/fileutils.rb:208:in `block in mkdir_p'
/usr/share/ruby/fileutils.rb:193:in `each'
/usr/share/ruby/fileutils.rb:193:in `mkdir_p'
...


Expected results:
perhaps just ERROR message, without traceback?

Additional info:

Comment 2 Jaroslav Henner 2019-11-12 16:45:54 UTC
I found this during verifying the 1767895 so I am attaching it.

Comment 3 Nick LaMuro 2019-12-16 23:46:33 UTC
Clearly I missed this getting assigned to me, so sorry for the delay.

I pretty much agree that we probably should handle this better, but I think it would be a question to involve UX with, since the code that would be handling the error probably would exist for all three entry points for creating a database backup:

1. using the "ops UI"
2. using that manageiq-console
3. using the raw rake tasks


My initial thought for how to handle this so we aren't being so verbose in all cases:


- Raise the exception normally, but catch it and only log the exception/backtrace into the logs
- For the rake tasks, include a rescue for the error we raise when there is a permission denied, but only print the general permission denied message and exit with a specific exit code for this case
- In the appliance-console, when we exit with said code, make sure we display the error to the end user.  If that is too complex (requires parsing command output or something similar to do), at least print a message to what logs to check
- For the UI, raise an error, but capture it in the MiqSchedule and have it raise an UI error truncated message without needing the backtrace.  Backtrace can still be written to the log as well.



* * *


While the above seems reasonable from my perspective, I haven't seen any sort of management discussion or push to work on this.  So with that said, I don't think me starting on anything here makes sense until a broader discussion is had.


Dennis:  Does this seem reasonable as an assessment?  Should we just leave this open for the time being, but treat it as a backlog item for the time being?

Comment 4 dmetzger 2019-12-17 13:53:29 UTC
Leaving in 5.11.z and assigning to UX for input.

Comment 5 dmetzger 2021-02-15 19:31:16 UTC
Given CloudForms has entered Maintenance Phase with version 5.11 and having not future major / minor releases planned, closing this ticket as Won't Fix.