D19528: Making Scheduler robust against guiding problems

[Eric Dejouhanet]

TallFurryMan added a comment.


  >> Oh wow, so you investigated that too? I have the same observation about aborted jobs! Did you have a look at D19393 <https://phabricator.kde.org/D19393>? Coincidence :)
  > 
  > Nope. Maybe you should add me as a reviewer? :-)
  
  That patch was unfinished, but my obs setup accepts a list of differentials to apply when updating itself so I pushed it without reviewers. I like the fact that we both found the same issue at that location :)
  
  >> I need some time to examine the part about guiding : we need the suspension feature to be usable both with and without scheduler, and reading this I don't readily understand if that's OK.
  > 
  > Suspending works in both modes. If used with the scheduler, the scheduler thinks simply that capturing is running although capturing is suspended. Restarting a suspended guiding is handled by the capture module.
  
  Agreed, that's really cool.
  
  >> About aborted jobs set for restart, the approach here is slightly different from D19393 <https://phabricator.kde.org/D19393>. D19393 <https://phabricator.kde.org/D19393> is not trying to restart aborted jobs, only making sure they don't interfere with other jobs, specifically when the scheduler is running. I needed to include the scheduler running/not running part, but I don't recall why now (I'm in business trip).
  > 
  > One thing with aborted jobs is not so nice currently: They are put at the end of the list, i.e. sorting of targets is changed, when aborted jobs get restarted.
  
  I propose you keep your differential focused on restoring functionality after a guiding failure, even if the aborted job isn't managed that well afterwards (that means not bypassing of aborted jobs at the beginning of evaluation).
  I will rebase D19393 <https://phabricator.kde.org/D19393> on yours, and add a fix to the block removing jobs that are not to be evaluated, so that aborted jobs are kept in place and not touched until they are the only ones remaining.
  In this context, I will tackle both the re-evaluation without order change and possible state instabilities like the altitude restriction causing the job to repeatedly abort and reschedule.
  
  What do you think?

REPOSITORY
  R321 KStars

REVISION DETAIL
  https://phabricator.kde.org/D19528

To: wreissenberger, mutlaqja, TallFurryMan
Cc: kde-edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20190306/1b7cd69b/attachment.html>