[Fuego] Fuego's version up and other changes

Daniel Sangorrin daniel.sangorrin at toshiba.co.jp
Thu Feb 2 05:45:54 UTC 2017


Hi Jan-Simon,

> -----Original Message-----
> From: Jan-Simon Möller [mailto:dl9pf at gmx.de]
> > - In my next branch, test specs have the ability to define which links
> > should be available after the test is complete. I'm using the Description
> > Setter plugin for that. Do you think that would be possible with the jjb
> > approach?.
> 
> Links ... let me see
> http://docs.openstack.org/infra/jenkins-job-builder/publishers.html#publishers.description-setter ?
> should work
> 
> For reference:
> http://docs.openstack.org/infra/jenkins-job-builder/definition.html
> http://docs.openstack.org/infra/jenkins-job-builder/builders.html
> http://docs.openstack.org/infra/jenkins-job-builder/publishers.html

Nice.
I think we can use it as the back end of the fuego xxx scripts. Hopefully jjb
also handles different versions of jenkins for us.

> We access the board very early even before the build (pre_test).
> The we build, deploy, run, fetch results, analyse. At this point

Ok, I know what you mean now. I think there is a trade-off between
complexity and performance. In this particular case, IMHO I think we 
won't gain much for the complexity that having multiple timeouts would add.
One timeout for the whole job is simple and easy to set by the user.
Suppose a test costs 20m to complete. Separating 20 seconds for the reboot
time is not really that important.
Also running jobs in parallel on the same board is not a good idea, even if you
schedule them in phases because some  tests may affect other tests
in different ways.

> > > - Integration of board up/down could happen in a few ways:
> > > -- Either ppl should just generate a wrapper around the (blocking) batch
> > > job and trigger it>
> > > with their pre/post to their needs. Done.
> > > -- Or we allow hooks like the current "TARGET_SETUP_LINK" and amend it
> > > with a matching "TARGET_TEARDOWN_LINK">
> > > - If a model like the "TARGET_SETUP_LINK" is used, we add a delay here as
> > > this call must block until the board is up.>
> > > In this case our predifined timeouts are bogus as they track not just the
> > > test run, but all processing.
> > Good point. I wasn't using the reboot feature so I hadn't thought about it.
> > I guess we would need to define a timeout for the board to reboot, and then
> > the timeout for each test. The timeout for the board could be called
> > BOARD_REBOOT_TIMEOUT for example and be defined in the asdf.board file. And
> > the timeout for each test defined in another variable such as TEST_TIMEOUT.
> 
> As I said, there are multiple ways to integrate that.
> a) The wrapper-job triggering the batch leaves fuego out of the picture. But we need to block the whole chain to make flow-control
> possible.
> b) TARGET_SETUP_LINK gives us a _per job_ way of brining up the board. Not just for the wrapp'ed batch.

Not sure I understand you but if b) means that when you click on the batch job, all the dependent individual jobs are triggered and execute with their own timeouts (and possibly reboot). 
This is actually how it is in my next branch. For the reboots this could be easily done by adding the reboot flag to each test (otherwise by default it doesn't reboot) on the testplan.

a) seems like a subset of b) where all REBOOT flags are set to 0 except the one for the batch job. 
 
> Most users might get away and be happy with a) . While a per-job control as in b) might scale better if you think of the case that you
> could have
> multiple target boards of the same type (multiple executors!) and could run jobs 'in parallel' !

I would prefer b). And a) being a subset of b) we can make everyone happy.

Cheers
Daniel







More information about the Fuego mailing list