canonical-ci-engineering team mailing list archive

[Francis Ginther <francis.ginther@xxxxxxxxxxxxx>]

Lets see...

On Wed, Oct 30, 2013 at 8:06 AM, Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx> wrote:
>
> This was discussed a couple of hours ago in ##qa and I think this is
> worth starting the discussion here to keep track.
>
> <jibel> vila, I was reading the updates you're doing to the CI doc (https://wiki.canonical.com/UbuntuEngineering/CI/NewRelease). To be clear running otto on another release that its target release is pointless and can only break things more than they are.
> <jibel> vila, the main purpose of this tool is to run tests on hardware without having to reprovision the system between each run and also have rollback features, ...
> <jibel> vila, so the kernel on the host and the content of the container must absolutely match

Why, is this an LXC requirement? I've never come across any
documentation that kernels must match. The reason otto is being used
is that does the necessary provisioning and rollback needed to test
packages from a merge proposal and did it quickly by running on
hardware. Our former solution of running on running on VMs took 3x
longer and caused more transient test failures.

> <jibel> vila, when I read "The rationale being that trusty is not required on the host for upstream-merger needs." it means that you don't need otto and a simple chroot would be enough

Sure, but otto was available.

> <vila> jibel: right, I'm documenting the existing setup. Why this has been chosen in the past... is ~unknown. I suspect it was the path of least resistance when setting up upstream-merger
> <jibel> vila, oh and also don't confuse otto which is the lxc/iso/overlayfs based tool and the runner you use to execute the tests
> <jibel> vila, the runner can be anything
> <vila> and I need to double check the rationale with fginther|away
> * vila nods
> <jibel> vila, it was maybe the interest for the AP runner but this part doesn't really requires otto and perhaps the gathering of the logs. But setting the right environment should be enough.
> <jibel> vila, I use it for ubiquity tests which doesn't use otto at all and run in VMs.
> <vila> jibel: I think the set ppas, install packages, use hooks stuff was the desired features, see the build step in http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/configure for example
> <jibel> argh :(
> <vila> jibel: it works for now but clearly needs some love
> <jibel> vila, I hope this execution step is generated at least :)
> <jibel> vila, why it is forked http://bazaar.launchpad.net/~canonical-ci-engineering/jenkins-launchpad-plugin/autopilot-testrunner-otto-trusty/view/head:/run_otto_job
> <jibel> ?
> <vila> jibel: no idea
> <jibel> vila, it seems to be adding options, and a specific option for local branch
> <vila> jibel: and given that we cloned the saucy job to create the trusty one, I doubt it's generated

I'm not sure I understand the question. The jenkins job is not
generated. The job and the testrunner branch do the extra work of
installing the test packages and PPAs provided by the parent jenkins
job. No objection to it needing some love, however once are able to do
this testing reliably on a canonistack/prodstack VM, this whole thing
can go away.

Francis

>
>        Vincent
>
> --
> Mailing list: https://launchpad.net/~canonical-ci-engineering
> Post to     : canonical-ci-engineering@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~canonical-ci-engineering
> More help   : https://help.launchpad.net/ListHelp



-- 
Francis Ginther
Canonical - Ubuntu Engineering - Continuous Integration Team