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:
I found this during verifying the 1767895 so I am attaching it.
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?
Leaving in 5.11.z and assigning to UX for input.
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.