<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 26, 2018 at 2:05 PM Balázs Gibizer <<a href="mailto:balazs.gibizer@ericsson.com">balazs.gibizer@ericsson.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_278820988826555562geary-body"><div>Hi, </div><div><br></div><div>I'm getting more and more confused how the zuul job hierarchy works or is supposed to work.</div><div><br></div><div>First there was a bug in nova that some functional tests are not triggered although the job (re-)definition in the nova part of the project-config should not prevent it to run [1].</div><div><br></div><div>There we figured out that irrelevant-files parameter of the jobs are not something that can be overriden during re-definition or through parent-child relationship. The base job openstack-tox-functional has an irrelevant-files attribute that lists '^doc/.*$' as a path to be ignored [2]. In the other hand the nova part of the project-config tries to make this ignore less broad by adding only '^doc/source/.*$' . This does not work as we expected and the job did not run on changes that only affected ./doc/notification_samples path. We are fixing it by defining our own functional job in nova tree [4].</div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/nova/+bug/1742962" target="_blank">https://bugs.launchpad.net/nova/+bug/1742962</a></div><div>[2] <a href="https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380" target="_blank">https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380</a></div><div>[3] <a href="https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509" target="_blank">https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509</a></div><div>[4] <a href="https://review.openstack.org/#/c/533210/" target="_blank">https://review.openstack.org/#/c/533210/</a></div><div><br></div><div>Then I started looking into other jobs to see if we made similar mistakes. I found two other examples in the nova related jobs where redefining the irrelevant-files of a job caused problems. In these examples nova tried to ignore more paths during the override than what was originally ignored in the job definition but that did not work [5][6]. </div><div><br></div><div>[5] <a href="https://bugs.launchpad.net/nova/+bug/1745405" target="_blank">https://bugs.launchpad.net/nova/+bug/1745405</a> (temptest-full)</div><div>[6] <a href="https://bugs.launchpad.net/nova/+bug/1745431" target="_blank">https://bugs.launchpad.net/nova/+bug/1745431</a> (neutron-grenade)</div><div><br></div><div>So far the problem seemed to be consistent (i.e. override does not work). But then I looked into neutron-grenade-multinode. That job is defined in neutron tree (like neutron-grenade) </div></div></blockquote><div><br></div><div>That is wrong and it should not have happened. </div><div>Grenade jobs that are shared by all the repos in the integrated gate should live in repos owned by QA/infra - it was never the plan for them to end up in the neutron repo.</div><div>We're working on making grenade and multinode zuulv3 native jobs. Grenade jobs will leave in the grenade repo, once they're ready we will remove the legacy one from neutron side and add the new ones defined in grenade. Changes will be done to the job template accordingly which means that for teams that are consuming those jobs via the template only there'll be no action.</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"><div id="m_278820988826555562geary-body"><div>but nova also refers to it in nova section of the project-config with different irrelevant-files than their original definition. So I assumed that this will lead to similar problem than in case of neutron-grenade, but it doesn't. </div><div><br></div><div><div>The neutron-grenade-multinode original definition [1] does not try to ignore the 'nova/tests' path but the nova side of the definition in the project config does try to ignore that path [8]. Interestingly a patch in nova that only changes under the path: nova/tests/ does not trigger the job [9]. So in this case overriding the irrelevant-files of a job works. (It seems that overriding neutron-tempest-linuxbridge irrelevant-files works too). </div><div><br></div><div>[7] <a href="https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159" target="_blank">https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159</a></div><div>[8] <a href="https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530" target="_blank">https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530</a></div></div><div>[9] <a href="https://review.openstack.org/#/c/537936/" target="_blank">https://review.openstack.org/#/c/537936/</a> </div><div><br></div><div>I don't see what is the difference between neutron-grenade and neutron-grenade-multinode jobs definitions from this perspective but it seems that the irrelevent-files attribute behaves inconsistently in these two jobs. Could you please help me undestand how irrelevant-files in overriden jobs supposed to work?</div><div><br></div><div>cheers,</div><div>gibi</div><div><br></div><div><br></div><div><br></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>