<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 15 March 2016 at 20:34, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Mar 15, 2016 at 09:04:48AM -0400, Jeff Darcy wrote:<br>
> > Yes, Right now we get the machine from duffy instantly. If it is not instant,<br>
> > it means no machines are in ready state and we will have to wait few more<br>
> > minutes (~5 minutes) to get them.<br>
><br>
> If machines are available to be allocated instantly, does that mean they're<br>
> being re-used across allocations? Or are there just so many extra machines<br>
> in the pool that there's time to re-provision in the background before they<br>
> get re-used again?<br>
<br>
</span>Yes, indeed. Once a test has been run and the machine is released back<br>
to Duffy, it will get cleanly installed. Last time the CentOS team<br>
explained about their community CI, they had ~250 physical machines for<br>
testing available. Details are in their wiki:<br>
<a href="https://wiki.centos.org/QaWiki/PubHardware" rel="noreferrer" target="_blank">https://wiki.centos.org/QaWiki/PubHardware</a><br>
<span class=""><br>
> > But I think vagrant is very useful anywhere else (in non CentOS CI infra).<br>
> > But I wasn't sure *in* CentOS CI, since the machines required for distaf are<br>
> > available via duffy. So I wasn't sure where vagrant would fit in.<br>
> ><br>
> > But if the plan is to run the existing regression tests by spawning vms<br>
> > inside the machines provided by duffy, then I think it can be done. Although<br>
> > someone will have to try that out see if it provides any advantage.<br>
><br>
> I think the advantages would be two-fold.<br>
><br>
> (a) The environment within a vagrant box is one we can control more than<br>
> might be possible within duffy.<br>
><br>
> (b) It's an environment that we can replicate with certainty in other<br>
> host environments where duffy doesn't exist.<br>
<br>
</span>(c) it would be possible to run tests on non-CentOS distributions<br>
<br>
We can place the Vagrant box files/images/whatever on<br>
<a href="http://artifacts.ci.centos.org" rel="noreferrer" target="_blank">artifacts.ci.centos.org</a> so that all systems in the CI have local access<br>
to them. Let me know if you want me to get that done and someone else<br>
can then configure a Jenkins job to run tests in Vagrant. It'll<br>
basically need scripts like these:<br>
<a href="https://github.com/gluster/glusterfs-patch-acceptance-tests/tree/master/centos-ci/libgfapi-python" rel="noreferrer" target="_blank">https://github.com/gluster/glusterfs-patch-acceptance-tests/tree/master/centos-ci/libgfapi-python</a></blockquote><div><br></div><div>So these vagrant images have to be run on the machines provisioned by duffy. Depending on the configuration of that machines we can have more than one vagrant image running there. Perhaps that will solve our problem of not having an extra disk for testing. But I still think it would be an overkill to run them inside the duffy machines.</div><div><br></div><div>But in any case, distaf tests *can* run inside vagrant images, as long as they have sshd running and can be connected with an IP address. So we can actually try to it out.</div><div><br></div><div>Best Regards,</div><div>Vishwanath</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<span class="HOEnZb"><font color="#888888"><br>
Niels<br>
</font></span></blockquote></div><br></div></div>