<html><body><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000"><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Gianluca Cecchi" &lt;gianluca.cecchi@gmail.com&gt;<br><b>To: </b>"Sven Kieske" &lt;s.kieske@mittwald.de&gt;<br><b>Cc: </b>"Allon Mureinik" &lt;amureini@redhat.com&gt;, "users" &lt;users@ovirt.org&gt;<br><b>Sent: </b>Wednesday, September 10, 2014 10:57:27 AM<br><b>Subject: </b>Re: [ovirt-users] qemu-kvm-rhev on EL machines for oVirt 3.4.z ?<br><div><br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 10, 2014 at 9:44 AM, Sven Kieske <span dir="ltr">&lt;<a href="mailto:s.kieske@mittwald.de" target="_blank">s.kieske@mittwald.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br><div><br></div>
&gt; In the discussion on the patch [3], Dan raised the concern that 3.4.z is a mature z-stream, and adding this dependency on <a href="http://resources.ovirt.org" target="_blank">resources.ovirt.org</a>'s repos will effectively blocks all vdsm updates for users which don't have these repos enabled in their production environments.<br>
<br>
</span>I'm sorry but I don't understand this.<br></blockquote><div><br></div><div>Hello,</div><div>I directly put here what I see Dan wrote in the link provided and that it seemed to me more a warning than a blocker.. (eventually he may add further content...)</div><div><br></div><div>"</div><div><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em;color:rgb(53,53,53);font-family:sans-serif">Patch Set 2:</p><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em;color:rgb(53,53,53);font-family:sans-serif">I'm not sure that this is a good idea for a mature z-stream. If someone has installed ovirt-3.4 without enabling the <a href="http://resource.ovirt.org" target="_blank">resource.ovirt.org</a>'s repos, this patch effectively blocks all vdsm updates for him.</p><p style="margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em;color:rgb(53,53,53);font-family:sans-serif">If we really want this in ovirt-3.4.4, please explain why and warn about the downsides on <a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a>.</p></div><div>"</div><div><br></div><div>I don't completely understand too...</div><div>How could one have installed 3.4 without enabling &nbsp;<span style="color:rgb(53,53,53);font-family:sans-serif"><a href="http://resource.ovirt.org" target="_blank">resource.ovirt.org</a>'s repos?</span><br></div><div><span style="color:rgb(53,53,53);font-family:sans-serif">Afaik the most of us who used EL 6 for their infra, then in soe way installed the rhev qemu-kvm package or desired/asked to do so in some way...</span></div><div><span style="color:rgb(53,53,53);font-family:sans-serif"><br></span></div><div><span style="color:rgb(53,53,53);font-family:sans-serif">So I think that is this is clearly stated on release notes there should be no particular problem.</span></div><div><span style="color:rgb(53,53,53);font-family:sans-serif"><br></span></div><div><span style="color:rgb(53,53,53);font-family:sans-serif">Gianluca</span></div></div></div></div>
</blockquote><div>If we decide to move forward with this patch, we'll definitely provide qemu-kvm-rhev in the repo - the concern was indeed for users who don't have this enabled.</div><div>Unlike 3.5, the 3.4.z repo doesn't seem to provide any "3rd parties" that can't be built from oVirt's sources - so, theoretically, it can be installed without the repo enabled - and the discussion here is whether this is an interesting usecase or not.<br></div><div><br></div><div>My personal tendency is to go forward (with a release note, as suggested), but as noted, there is some disagreement (e.g., Dan's comment), so we're looking for additional opinions.</div></div></body></html>