[placement] zuul job dependencies for greater good?

Eric Fried openstack at fried.cc
Mon Feb 25 20:36:44 UTC 2019


-1 to serializing jobs with stop-on-first-failure. Human time (having to
iterate fixes one failed job at a time) is more valuable than computer
time. That's why we make computers. If you want quick feedback on
fast-running jobs (that are running in parallel with slower-running
jobs), zuul.o.o is available and easy to use.

If we wanted to get more efficient about our CI resources, there are
other possibilities I would prefer to see tried first. For example, do
we need a whole separate node to run each unit & functional job, or
could we run them in parallel (or even serially, since all together they
would probably still take less time than e.g. a tempest) on a single node?

I would also support a commit message tag (or something) that tells zuul
not to bother running CI right now. Or a way to go to zuul.o.o and yank
a patch out.

Realizing of course that these suggestions come from someone who uses
zuul in the most superficial way possible (like, I wouldn't know how to
write a... job? playbook? with a gun to my head) so they're probably
exponentially harder than using the thing Chris mentioned.

-efried



More information about the openstack-discuss mailing list