Install hook error due to modprobe 8021q failure

[Michael Foord]

On local provider, deployment of a charm can fail with an error similar to:

machine-1: 2014-08-06 09:19:28 ERROR juju.worker runner.go:219 exited "networker": command "lsmod | grep -q 8021q || modprobe 8021q" failed (code: 1, stdout: , stderr: modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/3.13.0-32-generic/modules.dep.bin'

or:

machine-1: 2014-08-05 21:27:06 ERROR juju.worker runner.go:219 exited "networker": command "lsmod | grep -q 8021q || modprobe 8021q" failed (code: 1, stdout: , stderr: FATAL: Could not load /lib/modules/3.13.0-32-generic/modules.dep: No such file or directory

modprobe in the lxc container is using the host path to attempt to load the module. This appears to be a symptom of the module not being loaded in the host.

After the install fails due to the uniter exiting (or "something") something fixes the problem as a "juju resolved --retry" almost always succeeds.

Logs attached.

[Michael Foord (mfoord)]

Note that "modprobe 8021q" on the host before starting the container should be a workaround.

[Dimiter Naydenov (dimitern)]

I'm marking this as Critical, as it happens on trunk and is a regression since we introduced the networker.

[Dimiter Naydenov (dimitern)]

Couple of thoughts:
1) Networker should not attempt to modprobe 8021q if there are no VLANs to configure
2) When running in an LXC container, we can't modprobe anything, so the networker should not even try.

[Dave Cheney (dave-cheney)]

I am downgrading this issue to high.

Justification:

* yes, it needs to be fixed for the next stable release but I do not believe it blocks other changes landing
* the build has been blocked for over a week, I feel the benefit of blocking the line for this change does not justify the cost of blocking the work of 5 teams.

[Dimiter Naydenov (dimitern)]

Fix committed, but not merged yet because juju-core trunk is blocked on 2 bugs.