<div dir="ltr">Hi Eric,  see my comments inline.<div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 21, 2016 at 4:38 PM, Eric Helms <span dir="ltr">&lt;<a href="mailto:ehelms@redhat.com" target="_blank">ehelms@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">I recall seeing some discussion of Lago vs Vagrant and how there could be some leverage between the two. We are currently using Lago in our release testing pipeline, however, for years now we&#39;ve been using Vagrant for deploying developer and production hand-on testing environments. There are benefits to how we test and build environments to centering on a singular technology. Thus, I had a few questions I was hoping to get some thoughts on:<div><br></div><div> 1) What was the outcome of the Lago vs Vagrant discussions?</div></div></blockquote><div><br></div><div>The outcome was understanding that Vagrant can defiantly help in a few flows which Lago is currently doing, for e.g Image handling and managing libvirt/other providers, </div><div>but probably not replace Lago completely, at least not at first.</div><div>We didn&#39;t got a chance to peruse this path yet, though we have an intern that is going to do a POC on it soon and hopefully help move forward with Vagrant integration. </div><div>In the meantime Lago has proven to be valuable tool for oVirt and being used now in CI for both stable and latest versions, so I do see it being supported and developed in the near future.</div><div><br></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> 2) How to reconcile the built up base of Vagrant use within our group with Lago (or how to sell switching to Lago)?</div></div></blockquote><div><br></div><div>It would be great if your group can help POC or move forward with testing Vagrant with Lago, so we&#39;ll have a better idea on where Lago (2.0?) is going... </div><div>unfortunately we have only 1.5 engineers on Lago ATM and they are mostly focused on supporting oVirt as the first &#39;customer&#39; which uses Lago in production CI.</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> 3) Do you see them as co-existing with different application points?</div></div></blockquote><div><br></div><div>Yes, as mentioned above, I&#39;d love to see Lago uses Vagrant when possible, and If we&#39;ll see in the future that It doesn&#39;t make sense to continue maintaining Lago as a layer on top of Vagrant,</div><div>We might consider migrating it to be a Vagrant plugin or similar, but I think its too soon to tell. </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><br></div><div><br></div><div>To give an example of a disconnect where centering technology would benefit, we do an installation test currently spinning up a Lago based environment. Users testing our builds are using our existing Vagrant setup to spin up environments. However, we aren&#39;t testing the setup and configuration users are using and we end up double building the techniques for setting up environments.</div><div><br></div><div><br></div><div>Thanks for any thoughts,</div><div>Eric</div></div>
<br>_______________________________________________<br>
lago-devel mailing list<br>
<a href="mailto:lago-devel@ovirt.org">lago-devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/lago-devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/lago-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHEV DevOps<br>EMEA ENG Virtualization R&amp;D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</div></div>