<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 31, 2022 at 2:43 PM Jehan-Guillaume de Rorthais <<a href="mailto:jgdr@dalibo.com">jgdr@dalibo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 31 Jan 2022 08:49:44 +0100<br>
Klaus Wenninger <<a href="mailto:kwenning@redhat.com" target="_blank">kwenning@redhat.com</a>> wrote:<br>
...<br>
> Depending on the environment it might make sense to think about<br>
> having the manual migration-step controlled by the cluster(s) using<br>
> booth. Just thinking - not a specialist on that topic ...<br>
<br>
Could you elaborate a bit on this?<br>
<br>
Boothd allows to start/stop a ressource in the cluster currently owning the<br>
associated ticket. In this regard, this could help to stop the resource on one<br>
side and start it on the other one.<br>
<br>
However, as far as I know, there's no action like migrate-to/migrate-from that<br>
could be executed across multiple clusters to deal with the migration steps<br>
between both clusters... or does it?<br></blockquote><div>Guess I hadn't thought that far. 'controlled' above is probably not the right</div><div>wording. 'safeguard' may be the better one. Was mainly thinking of a mechanism</div><div>that would prevent the initial cluster from starting the vm again if something</div><div>goes wrong with the sequence of actions described.</div><div>But of course the idea of using booth to actively trigger a migration sounds</div><div>appealing and generally useful.</div><div>Maybe something to put on the wishlist ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
++<br>
<br>
</blockquote></div></div>