[placement] zuul job dependencies for greater good?

Sean Mooney smooney at redhat.com
Mon Feb 25 20:59:55 UTC 2019


On Mon, 2019-02-25 at 14:36 -0600, Eric Fried wrote:
> -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.
im aware of the concurn with first failure. originally i had wanted
to split check into "precheck" and "check" where check would only run if
precheck passed. after talking to people about that a few weeks ago
i changed my perspetive to  we should have fastcheck and check which are
two piplines that run in parallel and get two  comments back from zuul.

so when the fast check job fishes it comment back with that set and
when the check job finshses you get teh second set.
gate would then require that fastcheck and check both have +1 form zuul
to run.
> 
> 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?
currently im not sure if zull has a way to express run  job 1 on a node and 
then run job 2  and then job 3...

if it does this could certenly help.
nova proably has the slowest unittests of any project because it proably has the most
taking 7-8 minutes to run on a fast laptop but compared to a 1 hour and 40 ish miniut temepst
run yes we could proably queue up all tox enevs on a singel vm and have it easily complete
before tempest.  those jobs would also benifit form sharing a pip cache on that vm as 95%
of the dependencies are probaly common betwen the tox env modul the python version.
> 
> 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