<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>I was under the impression you are thinking about a wrapper job you<br>
need to wrap around every job. This is a single, out of band, job. So<br>
it may not be that bad.<br>
You seem to imply that slaves managed by the Swarm plugin are not<br>
&#39;normal&#39; ssh-based slaves, so there might be something there we can<br>
exploit (For example, perhaps the swarm client JAR can be made to exit<br>
once the slave is brought offline, so we can wrap it in a script that<br>
will shut the slave down when it does).<br>
I will look deeper into this in my POC.<br>
<span class=""></span><br></blockquote></div><br></div><div class="gmail_extra">Arent there any ability to hook into shutdown process and delay it from the hook itself? There are vdsm hooks for that but I am not sure how pool scheduler interacts with it. Maybe we can ask on user list. As I see the ideal is to catch shutdown, than run some hook that will put skave to maintanance, wait for job to finish and than unblocks shutdown.<br><br></div><div class="gmail_extra">I had the same problem when I was thinking on how to get back migration for local disk slaves so auto balancing can be used for them. And the only troublesome was to interact with user land to have an idea about if it is safe. Sounds like feature request? <br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><div>Anton Marchukov<br>Senior Software Engineer - <span><span><font color="#888888"><span><span><font color="#888888"><span><span><font color="#888888">RHEV CI - </font></span></span></font></span></span>Red Hat</font></span></span><br><br></div></font></span></div></div></div></div>
</div></div>