<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018 at 3:16 PM Sagi Shnaidman <<a href="mailto:sshnaidm@redhat.com">sshnaidm@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi, Bogdan<br><br></div>I like the idea with undercloud job. Actually if undercloud fails, I'd stop all other jobs, because it doens't make sense to run them. Seeing the same failure in 10 jobs doesn't add too much. So maybe adding undercloud job as dependency for all multinode jobs would be great idea. I think it's worth to check also how long it will delay jobs. Will all jobs wait until undercloud job is running? Or they will be aborted when undercloud job is failing?<br><br></div>However I'm very sceptical about multinode containers and scenarios jobs, they could fail because of very different reasons, like race conditions in product or infra issues. Having skipping some of them will lead to more rechecks from devs trying to discover all problems in a row, which will delay the development process significantly.<br><br></div>Thanks<br></div></blockquote><div><br></div><div>I agree on both counts w/ Sagi here.</div><div>Thanks Sagi </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><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 14, 2018 at 7:15 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobreli@redhat.com" target="_blank">bdobreli@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">An update for your review please folks<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bogdan Dobrelya <bdobreli at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello.<br>
As Zuul documentation [0] explains, the names "check", "gate", and<br>
"post"  may be altered for more advanced pipelines. Is it doable to<br>
introduce, for particular openstack projects, multiple check<br>
stages/steps as check-1, check-2 and so on? And is it possible to make<br>
the consequent steps reusing environments from the previous steps<br>
finished with?<br>
<br>
Narrowing down to tripleo CI scope, the problem I'd want we to solve<br>
with this "virtual RFE", and using such multi-staged check pipelines,<br>
is reducing (ideally, de-duplicating) some of the common steps for<br>
existing CI jobs.<br>
</blockquote>
<br>
What you're describing sounds more like a job graph within a pipeline.<br>
See: <a href="https://docs.openstack.org/infra/zuul/user/config.html#attr-job.dependencies" rel="noreferrer" target="_blank">https://docs.openstack.org/infra/zuul/user/config.html#attr-job.dependencies</a><br>
for how to configure a job to run only after another job has completed.<br>
There is also a facility to pass data between such jobs.<br>
<br>
... (skipped) ...<br>
<br>
Creating a job graph to have one job use the results of the previous job<br>
can make sense in a lot of cases.  It doesn't always save *time*<br>
however.<br>
<br>
It's worth noting that in OpenStack's Zuul, we have made an explicit<br>
choice not to have long-running integration jobs depend on shorter pep8<br>
or tox jobs, and that's because we value developer time more than CPU<br>
time.  We would rather run all of the tests and return all of the<br>
results so a developer can fix all of the errors as quickly as possible,<br>
rather than forcing an iterative workflow where they have to fix all the<br>
whitespace issues before the CI system will tell them which actual tests<br>
broke.<br>
<br>
-Jim<br>
</blockquote>
<br>
I proposed a few zuul dependencies [0], [1] to tripleo CI pipelines for undercloud deployments vs upgrades testing (and some more). Given that those undercloud jobs have not so high fail rates though, I think Emilien is right in his comments and those would buy us nothing.<br>
<br>
>From the other side, what do you think folks of making the<br>
tripleo-ci-centos-7-3nodes-multinode depend on tripleo-ci-centos-7-containers-multinode [2]? The former seems quite faily and long running, and is non-voting. It deploys (see featuresets configs [3]*) a 3 nodes in HA fashion. And it seems almost never passing, when the containers-multinode fails - see the CI stats page [4]. I've found only a 2 cases there for the otherwise situation, when containers-multinode fails, but 3nodes-multinode passes. So cutting off those future failures via the dependency added, *would* buy us something and allow other jobs to wait less to commence, by a reasonable price of somewhat extended time of the main zuul pipeline. I think it makes sense and that extended CI time will not overhead the RDO CI execution times so much to become a problem. WDYT?<br>
<br>
[0] <a href="https://review.openstack.org/#/c/568275/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/568275/</a><br>
[1] <a href="https://review.openstack.org/#/c/568278/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/568278/</a><br>
[2] <a href="https://review.openstack.org/#/c/568326/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/568326/</a><br>
[3] <a href="https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html" rel="noreferrer" target="_blank">https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html</a><br>
[4] <a href="http://tripleo.org/cistatus.html" rel="noreferrer" target="_blank">http://tripleo.org/cistatus.html</a><br>
<br>
* ignore the column 1, it's obsolete, all CI jobs now using configs download AFAICT...<span class="m_4001181766346950640HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div class="m_4001181766346950640gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Best regards<br></div>Sagi Shnaidman<br></div></div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>