<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 26, 2018 at 5:57 PM James E. Blair <<a href="mailto:corvus@inaugust.com">corvus@inaugust.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Balázs Gibizer <<a href="mailto:balazs.gibizer@ericsson.com" target="_blank">balazs.gibizer@ericsson.com</a>> writes:<br>
<br>
> Hi,<br>
><br>
> I'm getting more and more confused how the zuul job hierarchy works or<br>
> is supposed to work.<br>
<br>
Hi!<br>
<br>
First, you (or others) may or may not have seen this already -- some of<br>
it didn't exist when we first rolled out v3, and some of it has changed<br>
-- but here are the relevant bits of the documentation that should help<br>
explain what's going on.  It helps to understand freezing:<br>
<br>
  <a href="https://docs.openstack.org/infra/zuul/user/config.html#job" rel="noreferrer" target="_blank">https://docs.openstack.org/infra/zuul/user/config.html#job</a><br>
<br>
and matching:<br>
<br>
  <a href="https://docs.openstack.org/infra/zuul/user/config.html#matchers" rel="noreferrer" target="_blank">https://docs.openstack.org/infra/zuul/user/config.html#matchers</a><br>
<br>
> First there was a bug in nova that some functional tests are not<br>
> triggered although the job (re-)definition in the nova part of the<br>
> project-config should not prevent it to run [1].<br>
><br>
> There we figured out that irrelevant-files parameter of the jobs are<br>
> not something that can be overriden during re-definition or through<br>
> parent-child relationship. The base job openstack-tox-functional has<br>
> an irrelevant-files attribute that lists '^doc/.*$' as a path to be<br>
> ignored [2]. In the other hand the nova part of the project-config<br>
> tries to make this ignore less broad by adding only '^doc/source/.*$'<br>
> . This does not work as we expected and the job did not run on changes<br>
> that only affected ./doc/notification_samples path. We are fixing it<br>
> by defining our own functional job in nova tree [4].<br>
><br>
> [1] <a href="https://bugs.launchpad.net/nova/+bug/1742962" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1742962</a><br>
> [2]<br>
> <a href="https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380" rel="noreferrer" target="_blank">https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380</a><br>
> [3]<br>
> <a href="https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509" rel="noreferrer" target="_blank">https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509</a><br>
> [4] <a href="https://review.openstack.org/#/c/533210/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/533210/</a><br>
<br>
This is correct.  The issue here is that the irrelevant-files definition<br>
on openstack-tox-functional is too broad.  We need to be *extremely*<br>
careful applying matchers to jobs like that.  Generally I think that<br>
irrelevant-files should be reserved for the project-pipeline invocations<br>
only.  That's how they were effectively used in Zuul v2, after all.<br>
<br>
Essentially, when someone puts an irrelevant-files section on a job like<br>
that, they are saying "this job will never apply to these files, ever."<br>
That's clearly not correct in this case.<br>
<br>
So our solutions are to acknowledge that it's over-broad, and reduce or<br>
eliminate the list in [2] and expand it elsewhere (as in [3]).  Or we<br>
can say "we were generally correct, but nova is extra special so it<br>
needs its own job".  If that's the choice, then I think [4] is a fine<br>
solution.<br>
<br>
> Then I started looking into other jobs to see if we made similar<br>
> mistakes. I found two other examples in the nova related jobs where<br>
> redefining the irrelevant-files of a job caused problems. In these<br>
> examples nova tried to ignore more paths during the override than what<br>
> was originally ignored in the job definition but that did not work<br>
> [5][6].<br>
><br>
> [5] <a href="https://bugs.launchpad.net/nova/+bug/1745405" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1745405</a> (temptest-full)<br>
<br>
As noted in that bug, the tempest-full job is invoked on nova via this<br>
stanza:<br>
<br>
<a href="https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10674-L10688" rel="noreferrer" target="_blank">https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10674-L10688</a><br>
<br>
As expected, that did not match.  There is a second invocation of<br>
tempest-full on nova here:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n126" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n126</a></blockquote><div><br></div><div>I guess the line number changed since so this has moved to L101 [1] now :).</div><div>tempest-full is part of the integrated-gate, so all projects in it run it through there.</div><div><br></div><div>[1] <a href="http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n101">http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n101</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
That has no irrelevant-files matches, and so matches everything.  If you<br>
drop the use of that template, it will work as expected.  Or, if you can<br>
say with some certainty that nova's irrelevant-files set is not<br>
over-broad, you could move the irrelevant-files from nova's invocation<br>
into the template, or even the job, and drop nova's individual<br>
invocation.<br>
<br></blockquote><div>I don't think projects in the integrated gate should remove themselves from the</div><div>template, it really helps keeping consistency. </div><div><br></div><div>The pattern I've seen is that most projects repeat the same list of irrelevant files</div><div>over and over again in all of their integration tests, It would be handy in future to</div><div>be able to set irrelevant-files on a template when it's consumed.</div><div>So we could have shared irrelevant files defined in the template, and custom ones</div><div>added by each project when consuming the template. I don't this is is possible today.</div><div>Does it sound like a reasonable feature request?</div><div><br></div><div>Andrea Frittoli (andreaf)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> [6] <a href="https://bugs.launchpad.net/nova/+bug/1745431" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1745431</a> (neutron-grenade)<br>
<br>
The same template invokes this job as well.<br>
<br>
> So far the problem seemed to be consistent (i.e. override does not<br>
> work). But then I looked into neutron-grenade-multinode. That job is<br>
> defined in neutron tree (like neutron-grenade) but nova also refers to<br>
> it in nova section of the project-config with different<br>
> irrelevant-files than their original definition. So I assumed that<br>
> this will lead to similar problem than in case of neutron-grenade, but<br>
> it doesn't.<br>
><br>
> The neutron-grenade-multinode original definition [1] does not try to<br>
> ignore the 'nova/tests' path but the nova side of the definition in<br>
> the project config does try to ignore that path [8]. Interestingly a<br>
> patch in nova that only changes under the path: nova/tests/ does not<br>
> trigger the job [9]. So in this case overriding the irrelevant-files<br>
> of a job works. (It seems that overriding neutron-tempest-linuxbridge<br>
> irrelevant-files works too).<br>
><br>
> [7]<br>
> <a href="https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159</a><br>
> [8]<br>
> <a href="https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530" rel="noreferrer" target="_blank">https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530</a><br>
> [9] <a href="https://review.openstack.org/#/c/537936/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/537936/</a><br>
><br>
> I don't see what is the difference between neutron-grenade and<br>
> neutron-grenade-multinode jobs definitions from this perspective but<br>
> it seems that the irrelevent-files attribute behaves  inconsistently<br>
> in these two jobs. Could you please help me undestand how<br>
> irrelevant-files in overriden jobs supposed to work?<br>
<br>
These jobs only have the one invocation -- on the nova project -- and<br>
are not added via a template.<br>
<br>
Hopefully that explains the difference.<br>
<br>
Basically, the irrelevant-files on at least one project-pipeline<br>
invocation of a job have to match, as well as at least one definition of<br>
the job.  So if both things have irrelevant-files, then it's effectively<br>
a union of the two.<br>
<br>
I used a tool to help verify some of the information in this message,<br>
especially the bugs [5] and [6].  You can ask Zuul to output debug<br>
information about its job selection if you're dealing with confusing<br>
situations like this.  I went ahead and pushed a new patchset to your<br>
test change to demonstrate how:<br>
<br>
  <a href="https://review.openstack.org/537936" rel="noreferrer" target="_blank">https://review.openstack.org/537936</a><br>
<br>
When it finishes running all the tests (in a few hours), it should<br>
include in its report debug information about the decision-making<br>
process for the jobs it ran.  It outputs similar information into the<br>
debug logs; so that we don't have to wait for it to see what it looks<br>
like here is that copy:<br>
<br>
  <a href="http://paste.openstack.org/show/653729/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/653729/</a><br>
<br>
The relevant lines for [5] are:<br>
<br>
2018-01-26 13:07:53,560 DEBUG zuul.layout: Pipeline variant <Job tempest-full branches: None source: openstack-infra/openstack-zuul-jobs/zuul.d/zuul-legacy-project-templates.yaml@master#126> matched <Change 0x7f2fed8883c8 537936,2><br>
2018-01-26 13:07:53,560 DEBUG zuul.layout: Pipeline variant <Job tempest-full branches: None source: openstack-infra/project-config/zuul.d/projects.yaml@master#10485> did not match <Change 0x7f2fed8883c8 537936,2><br>
<br>
Note the project-file-branch-line-number references are especially<br>
helpful.<br>
<br>
-Jim<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>
</blockquote></div></div>