[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH OSSTEST] README: discuss how to create and run an adhoc flight and/or job.



Ian Campbell writes ("[PATCH OSSTEST] README: discuss how to create and run an 
adhoc flight and/or job."):
> I also needed to document some of the more special runvars for
> reference purposes.
...
> +- Host Idents:
> +
> +    Most jobs require one or more hosts to operate on, these are
> +    passed to the ts-* commands making up the job as command line
> +    options given the "ident" of the host, which is simply an
> +    identifier for the role of the host. Most often a job which only
> +    requires a single host will have a single ident `host`, a
> +    migration job might involve `src_host' and `dst_host'.

Inconsistent use of ` vs '.

> +    In general the ident is simply passed to the ts-* scripts by
> +    sg-run-job or by ./standalone and is then converted to an actual
> +    host by looking for an identically named runvar.
> +
> +    This runvar is usually set by ts-hosts-allocate which in
> +    production mode interacts with the resource planner. However in
> +    some cases, e.g. bisection, this runvar is configured when the
> +    flight is constructed (so that bisection happens on the same host).

You should mention here, or refer to, the `ident=actualhost' syntax.

> +Thus the normal way to invoke cs-flight-create is:
> +
> +    $ flight=`./cs-flight-create adhoc adhoc`

ITYM

  +    $ flight=`./cs-flight-create adhoc adhoc`; echo $flight

> +Once you have an empty flights there are two main ways to populate it
> +with jobs. Firstly you can create jobs from scratch using
> +cs-job-create or secondly by copying one or more jobs from an existing
> +template flight using "cs-adjust-flight copy-jobs". In either case the
> +job can then be further customised using cs-adjust-flight to add and
> +remove runvars etc.

Mention cs-adjust-flight new: ?

> +cs-job-create requires a flight ($flight from above), a job name (any
> +string), a recipe (either custom, see below, or from any
> +run-job/<recipe> in sg-run-job) and then the runvars in key=value
> +form. Deciding on the runvars in particular can be tricky, it is
> +usually easiest to copy an existing job.

I never use cs-job-create by hand.

> +You will also want to provide the necessary buildjobs for the job. You
> +can do so by also copying the build jobs from your template job or by
> +creating them by hand, or by setting the buildjob to reuse the builds
> +done by the template, by setting the appropriate buildjob runvar to
> +"$template.$job" . See "Common/Special Runvars" above for more.

Mentioning the rune for this would probably be helpful.

> +A worked example, including a custom recipe (in this case to reboot
> +Xen five times on the host) and .
> +Custom sg-run-job-adhoc, requires a single host (ident "host") and
> +runs ts-host-reboot + a ping check 5 times:

"and .  Custom" ?

> +# Reuse the binaries from the Xen template job for both the hypervisor
> +# and the tools by pointing the buildjob and xenbuildjob runvars of
> +# $job at them. XXX assumes the binaries still exist (haven't been
> +# garbage collected).
> +./cs-adjust-flight $flight runvar-set $job buildjob $template.build-amd64
> +./cs-adjust-flight $flight runvar-set $job xenbuildjob $template.build-amd64

Better to say "." than "$job" I think.

> +# Copy Linux build job from template and reset the revision to build
> +# what we want.
> +./cs-adjust-flight $flight copy-jobs $template build-amd64-pvops
> +./cs-adjust-flight $flight runvar-set build-amd64-pvops revision_linux 
> $lnxrev

Here is a recent rune I used:

  ./cs-adjust-flight -v new:commission-baroque copy-jobs $template \
     /test-amd64-i386-freebsd10- runvar-perlop . /buildjob "s/^/$template./"


But all of this can be improved later, so

Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.