<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>If we need that extra server in Production DC (for hosted engine 
redundancy and to allow maintenance) then lets take the lower end new 
servers from 17-26 and replace it with the strong one.</div><div>We need
 to utilize our servers, I don&#39;t think we&#39;re at 50% utilization even, 
looking at the memory consumption last time i checked when all slaves 
were working</div></blockquote><div>the problem is that we won&#39;t have live migration in the Production cluster if we add<br> the new hosts there(because of the multi node NUMA mismatch), we could put 2 new<br>hosts in the Production cluster but then we would have to schedule a downtime<br></div><div>in order to move them.<br><br></div><div>I think that coupling the engine upgrade with the new slaves is not necessary.<br></div><div>we can start by installing the hook on ovirt-srv11 and spinning up new slaves,<br></div><div>that way we can also test the hook in production. because there is no NFS involved,<br></div><div>and live migration isn&#39;t working with the hook, the host is pretty much self-contained<br></div><div>and this can&#39;t harm anything. <br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 4:59 PM, Anton Marchukov <span dir="ltr">&lt;<a href="mailto:amarchuk@redhat.com" target="_blank">amarchuk@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span></span><span></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was talking about using the hooks before installing the ssds, but if that can<br>
be done reliably also before the upgrade it&#39;s also a solution that will help<br>
scratch our current itches sooner.<br></blockquote><div><br></div></span><div>That&#39;s about it. The hook in 3.6 contains the patch I submitted. It does not work without it at all. <br>Although you can use rpm from 3.5 in 3.6.<br></div><span class=""><div> <span></span><br><span></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>^ well, the machines being slaves I think there&#39;s no problem having to stop<br>
them to migrate them, we have already experience with both fabric and jenkins<br>
so I guess it should not be hard to automate with those tools ;)<br></blockquote><div><br></div></span><div>Yes there is no problem with that. But I am not aware about &quot;stop all slaves on the host&quot; feature in<br>oVirt so that would be either manually clicking or we need to fabricate it. Not a big deal too.<br></div><div> </div></div><span class="">-- <br><div><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>
</span></div></div>
<br>_______________________________________________<br>
Infra mailing list<br>
<a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
<br></blockquote></div><br></div>