Lets see... On Wed, Oct 30, 2013 at 8:06 AM, Vincent Ladeuil <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~canonical-ci-engineering > More help : https://help.launchpad.net/ListHelp -- Francis Ginther Canonical - Ubuntu Engineering - Continuous Integration Team -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
