<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 12, 2016 at 2:13 PM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@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 class="HOEnZb"><div class="h5"><br>
<br>
On 10/12/2016 05:01 AM, Dmitry Tantsur wrote:<br>
> Hi folks!<br>
><br>
> I'd like to propose a plan on how to simultaneously extend the coverage of our<br>
> jobs and reduce their number.<br>
><br>
> Currently, we're running one instance per job. This was reasonable when the<br>
> coreos-based IPA image was the default, but now with tinyipa we can run up to 7<br>
> instances (and actually do it in the grenade job). I suggest we use 6 fake bm<br>
> nodes to make a single CI job cover many scenarios.<br>
><br>
> The jobs will be grouped based on driver (pxe_ipmitool and agent_ipmitool) to be<br>
> more in sync with how 3rd party CI does it. A special configuration option will<br>
> be used to enable multi-instance testing to avoid breaking 3rd party CI systems<br>
> that are not ready for it.<br>
><br>
> To ensure coverage, we'll only leave a required number of nodes "available", and<br>
> deploy all instances in parallel.<br>
><br>
> In the end, we'll have these jobs on ironic:<br>
> gate-tempest-ironic-pxe_<wbr>ipmitool-tinyipa<br>
> gate-tempest-ironic-agent_<wbr>ipmitool-tinyipa<br>
><br>
> Each job will cover the following scenarious:<br>
> * partition images:<br>
> ** with local boot:<br>
> ** 1. msdos partition table and BIOS boot<br>
> ** 2. GPT partition table and BIOS boot<br>
> ** 3. GPT partition table and UEFI boot  <*><br>
> ** with netboot:<br>
> ** 4. msdos partition table and BIOS boot <**><br>
> * whole disk images:<br>
> * 5. with msdos partition table embedded and BIOS boot<br>
> * 6. with GPT partition table embedded and UEFI boot  <*><br>
><br>
>  <*> - in the future, when we figure our UEFI testing<br>
>  <**> - we're moving away from defaulting to netboot, hence only one scenario<br>
><br>
> I suggest creating the jobs for Newton and Ocata, and starting with Xenial right<br>
> away.<br>
><br>
> Any comments, ideas and suggestions are welcome.<br>
<br>
</div></div>Huge +1 on this from me, as well.<br>
<br>
I am also in favor of some of the other suggestions on this thread, namely,<br>
moving API testing over to functional tests so that those can be run more<br>
quickly / with less resources / without affecting tempest scenario tests.<br>
<br>
I also think we should begin defining additional scenario tests to cover things<br>
we are not covering today  (eg, adopt a running instance), as Vasyl already<br>
pointed out. But I don't think that conflicts or prevents the changes you're<br>
suggesting, Dmitry.<br>
<br>
-Deva<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>++</div><div><br></div><div>Thanks for bringing this up Dmitry! Might I suggest, if we don't already have it, that this would be a good time to track (in a spreadsheet-like form), the jobs with the tests covered by each job (or desired but not covered yet). I can never remember what we are testing vs not testing. (e.g. I thought we had adoption of a running instance.)</div><div><br></div><div>--ruby</div><div><br></div></div></div></div>