Description of problem: This is because backup can clog up network and use a lot of I\O when these resources are short and we want user to be aware this may be because of backup. Errors will mention repeating issues may be caused by this, but it could also be unrelated.
(In reply to Yaniv Dary from comment #0) > Description of problem: > This is because backup can clog up network and use a lot of I\O when these > resources are short and we want user to be aware this may be because of > backup. > > Errors will mention repeating issues may be caused by this, but it could > also be unrelated. I suggest we review this carefully. I do not see how a simple SQL sequence can know something about the peripherals. It is the responsibility of a monitoring system to handle these issues as it has all the information.
(In reply to Doron Fediuck from comment #1) > (In reply to Yaniv Dary from comment #0) > > Description of problem: > > This is because backup can clog up network and use a lot of I\O when these > > resources are short and we want user to be aware this may be because of > > backup. > > > > Errors will mention repeating issues may be caused by this, but it could > > also be unrelated. > > I suggest we review this carefully. > I do not see how a simple SQL sequence can know something about the > peripherals. It is the responsibility of a monitoring system to handle > these issues as it has all the information. What monitoring software? 3rd party will probably would not be aware of virt related affects on network\IO hogging. We should have events on backup start\completion\failure to know that backup is running.
(In reply to Yaniv Dary from comment #2) > (In reply to Doron Fediuck from comment #1) > > (In reply to Yaniv Dary from comment #0) > > > Description of problem: > > > This is because backup can clog up network and use a lot of I\O when these > > > resources are short and we want user to be aware this may be because of > > > backup. > > > > > > Errors will mention repeating issues may be caused by this, but it could > > > also be unrelated. > > > > I suggest we review this carefully. > > I do not see how a simple SQL sequence can know something about the > > peripherals. It is the responsibility of a monitoring system to handle > > these issues as it has all the information. > > What monitoring software? 3rd party will probably would not be aware of virt > related affects on network\IO hogging. > We should have events on backup start\completion\failure to know that backup > is running. We will have start\end events, but you can not deduce that any error which occurs during the backup is related to the backup. For example, if a host fails during backup or CPU spikes it has nothing to do with the backup. Bottom line, other than start/stop events (with status and stack trace the backup process gets) we cannot guarantee anything else since we do not have the knowledge. I suggest to close this RFE and focus on Bug 1188143.
(In reply to Doron Fediuck from comment #3) > (In reply to Yaniv Dary from comment #2) > > (In reply to Doron Fediuck from comment #1) > > > (In reply to Yaniv Dary from comment #0) > > > > Description of problem: > > > > This is because backup can clog up network and use a lot of I\O when these > > > > resources are short and we want user to be aware this may be because of > > > > backup. > > > > > > > > Errors will mention repeating issues may be caused by this, but it could > > > > also be unrelated. > > > > > > I suggest we review this carefully. > > > I do not see how a simple SQL sequence can know something about the > > > peripherals. It is the responsibility of a monitoring system to handle > > > these issues as it has all the information. > > > > What monitoring software? 3rd party will probably would not be aware of virt > > related affects on network\IO hogging. > > We should have events on backup start\completion\failure to know that backup > > is running. > > We will have start\end events, but you can not deduce that any error which > occurs during the backup is related to the backup. For example, if a host > fails during backup or CPU spikes it has nothing to do with the backup. > Bottom line, other than start/stop events (with status and stack trace the > backup process gets) we cannot guarantee anything else since we do not have > the knowledge. > I suggest to close this RFE and focus on Bug 1188143. Since we will not run the tool automatically, I will close this one. I hope that if some try to automate backup, he will not start getting issues without knowing the cause.