support usage with lxc

[kapilt]

i was able to get weave working with lxc, a one line change to the front end shell script, it would be nice to see this supported, either via a refactoring of the shell script, (container type option with default of docker) or other means. The sheer and growing size of the front end shell script seems to preclude a separate front end script for lxc and the install mechanism would prefer not want it to be split i assume. Diff for fwiw

diff ~/src/github.com/zettio/weave/weaver/weave files/weave-lxc 
120c120
<     CONTAINER_PID=$(docker inspect --format='{{ .State.Pid }}' $CONTAINER)

---
>     CONTAINER_PID=$(sudo lxc-info -n $CONTAINER -p -H)

[update] to clarify with that diff (post weave running) i can weave attach to running lxc containers by name.

[rade]

AFAICT, this change would allow weave attach to work with lxc containers; weave launch etc would still use docker, i.e. the weave router would be run via docker. And weave run would still use docker too. Correct?

So would a better summary of this issue be "support attaching of lxc containers"?

PS: you'll probably also want to change https://github.com/hesco/weave/blob/master/weaver/weave#L150 PPS: the changes do also affect weave launch and weave run, since that code is shared, i.e. they'd start containers with docker but attempt to obtain their pid via lxc, which isn't great.

[kapilt]

nutshell yes that's a better summary of the diff. i'm looking at making it a bit more seamless (separate daemon) such that normal lxc usage automatically gets a weave network device. Part of the issue is that a significant portion of the logic and setup of weave is in the shell, and that shell script semantics are fairly intimately tied to docker. ie there's no reason i need to run weave in a docker container vs a daemon on the host, and the device attachment could be done via an lxc hook (man lxc.container.conf). ie. weave doesn't need to be the frontend to the container implementation, it could be integrated in using the implementation's facility for network integration. That needs some coordination and policy logic atm, ie. atm i users are required to determine each container's address individually. simpler direct tool integration assumes an external system for automation and coordination (hence the additional daemon in my case) of user policies for address assignment.

[rade]

a significant portion of the logic and setup of weave is in the shell, and that shell script semantics are fairly intimately tied to docker. ie there's no reason i need to run weave in a docker container vs a daemon on the host

Yep, the weave router itself knows nothing about docker or even containers.

The tie-in to docker as the specific containerisation technology is probably less strong than it may first appear; as you discovered yourself by getting lxc containers attached to weave with a single line change. So the weave script could conceivably be modified to accommodate lxc w/o turning into a giant spaghetti bowl.

[rade]

So the weave script could conceivably be modified to accommodate lxc w/o turning into a giant spaghetti bowl.

Having said that, I suspect more docker specifics will be introduced over time, so a fork may be a better long-term strategy.

[kapilt]

I'd prefer to avoid a complete fork especially given the frequency of changes to that file. ideal would be a set of library functions that either front end could call out to, or making the weave script itself the library (perhaps via $0 detection or param though the latter technique is shell specific, will have to explore more), sound reasonable? although i wonder in the latter case (weave script as lib) that there might be more chance for breakage without some ci.

[rade]

The trouble with splitting the file is that then users have to download two files. And it doesn't solve the fundamental problem you have identified, i.e. things are changing with a high frequency; any library functions we extract would be just as unstable - their signatures and functionality changes - as they are now.

Things are actually less likely to break with a fork. Remarkably few changes involve both the weave router and the script, i.e. the script tends to continue working for many versions of the router and vice versa.

[kapilt]

fair enough, i'll continue with a separate script for now. thanks. leaving this open for pull request.

[bmullan]

Kapil were you ever able to get weave to work w/LXC with the launch etc additional weave functions?