[Pkg-swan-devel] Bug#926479: [Fwd: Bug#926479: Interesting ..]

[Christian Ehrhardt]

On Mon, Apr 8, 2019 at 8:22 PM Paul Gevers <elbrus at debian.org> 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