<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 6:27 PM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div>between problems solved in upcoming 4.1.3 release I see this:</div><div><br></div><div>Lost Connection After Host Deploy when 4.1.3 Host Added to 4.1.2 Engine</div><div>tracked by<br><div><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1459484" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1459484</a></div></div></div></blockquote><div><br></div><div>I *think* the specific bug was discovered (and fixed) while developing 4.1.3.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div></div><div><br></div><div>As a matter of principle I would prefer to force that an engine version must be greater or equal than all the hosts it is intended to manage.</div><div>I don't find safe to allow this and probably unnecessary maintenance work... what do you think?</div><div><br></div><div>For example if you go here:</div><div><a href="http://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&1=&2=" target="_blank">http://www.vmware.com/<wbr>resources/compatibility/sim/<wbr>interop_matrix.php#interop&1=&<wbr>2=</a><br></div><div><br></div><div>you can see that:</div><div>- a vCenter Server 5.0U3 cannot manage an ESXi 5.1 host</div><div>- a vCenter Server 5.1U3 cannot manage an ESXi 6.0 host</div><div>- a vCenter Server 6.0U3 cannot manage an ESXi 6.5 host</div></div></blockquote><div><br></div><div>We are more flexible ;-)</div><div><br></div><div>While I think it's a matter of taste, I think there are merits to upgrading the hosts first. For example, assuming you have many hosts, to me it makes sense to upgrade just one, see that things work well. Then, upgrade another, perform live migration, etc, see that it's smooth, before upgrading the manager, which is a bigger task sometimes (rollback is more challenging, for example, it has a downtime requirements where as single host maintenance is not requiring the same level of downtime, etc.).</div><div>In addition, there are host-based features (VDSM hooks) which do not mandate a manager upgrade.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>In my opinion an administrator of the virtual infrastructure doesn't expect to be able to manage newer versions' hosts with older engines... and probably he/she doesn't feel this feature as a value added.</div></div></blockquote><div><br></div><div>I'm on your side on this, as I believe the manager should always be the most up-to-date, but I know others have different opinions and we'd like to keep it that way.</div><div>Y.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Just my thoughts.</div><div>Cheers,</div><div>Gianluca</div></div>
<br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
<br></blockquote></div><br></div></div>