On Mon, Apr 8, 2019 at 8:22 PM Paul Gevers <[email protected]> wrote: > > Hi, > > On 08-04-2019 12:03, Yves-Alexis Perez wrote: > > Christian replied to me and the bug but not you so in case you're not > > actively > > monitoring the bug I'm forwarding it as well. > > Thanks, I am not watching the bug indeed. > > > What is your opinion on the proposal at the end? > > Perfect solution if the test indeed needs that. If it does, I don't > understand why it passes sometimes, as all the workers on ci.d.n should > be the same. Maybe the lxc leaks a bit?
Odd for sure - at least for my local debian container tests it was a 100% hit rate. And in VMs it always worked (as does the Ubuntu CI that I linked) Furthermore there is a reason I never thought I'd need to add isolation-machine which is that it works well for Ubuntu on armhf which runs in LXD containers as well. I was logging in and checking the service status, in the Ubuntu image it just starts. But then - even thou Yves and I worked a lot to reduce it - there also is some Delta left. For example we have the kernel-libipsec plugin which allows it to run without modules as well as a fix for [1]. Examples in our CI - old [3] new [2]. [1]: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1780534 [2]: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/s/strongswan/20190406_005838_2bf72@/log.gz [3]: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/s/strongswan/20190207_031313_a233f@/log.gz i was retrying local amd64 execution with a Ubuntu 19.04 container and it confirms that only Debian is affected by this. While I don't understand yet why I'm glad that we found it. Everytime I do a merge of strongswan in Ubuntu Yves and I work together to reduce the Delta. But the biggest chunks we postponed for after buster. Seeing the results above I'm rather sure that would resolve the issues as well. I was looking forward to that anyway ... /me feels better now understanding why it fails for you, but not for us - In hindsight, sorry Yves to pass you a test not being 100% valid for you. > But this change would be even acceptable for an unblock if it can happen > soon (without any other changes). I wondered about that, but I see that it will make CI on the package for the lifetime of buster more helpful. > I am seriously wondering if the last test doesn't *also* need a > isolation-machine restriction. It seems to me that modprobe isn't > available in a linux container. I yesterday only looked at the one test that was reported failing. I tested it again and the plugins test works in a container, maybe it just doesn't need the service up. You are still right, while it seems to work atm it might as well turn out to be unreliable. If we change it anyway, then I agree that it seems wise to move "plugins" down as well to be on the safe side. Overall that would then look like this: diff --git a/debian/tests/control b/debian/tests/control index eb9e20463c..5b1ebf32c8 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,3 +1,7 @@ -Tests: daemon admin-strongswan-charon admin-strongswan-starter plugins -Depends: strongswan, libstrongswan-standard-plugins, libstrongswan-extra-plugins, libcharon-extra-plugins, strongswan-pki, strongswan-scepclient +Tests: admin-strongswan-charon admin-strongswan-starter +Depends: strongswan, strongswan-pki, strongswan-scepclient Restrictions: needs-root isolation-container allow-stderr + +Tests: daemon plugins +Depends: strongswan-starter, libstrongswan-standard-plugins, libstrongswan-extra-plugins, libcharon-extra-plugins +Restrictions: needs-root isolation-machine allow-stderr > Paul > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
