Hi Chris,
On 08/17/2018 04:25 PM, Christian Gagneraud wrote:
On 16 August 2018 at 06:55, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
You can either create vcan's inside that namespace or you can create a vcan
(in the init namespace) and move it to the (docker) namespace by assigning
that CAN interface to that namespace. The same that I suggested on slide 20
with real CAN interfaces.
Got you, i do not need vxcan to play with namespaces, vcan and can now
both support it.
Yes. And every CAN_RAW, CAN_BCM socket as well as CAN_GW is namespace
aware. So the only reason for vxcan is to exchange CAN frames between
different namespaces (or the root namespace).
I discovered NS very, very recently. And w/o manipulating them at the
low-level, I think my above comments stands "kind of right".
You cannot do much with vcan by just using the "docker" command line,
you need to get your hands "dirty" and use iproute2 to manipulate NS.
Maybe this is something that can be added to docker, that you can create
vcan's and can-gw rules at startup without urging the docker instance to
have root capabilities.
Going further wrt vxcan, I still need the "two plugs" of the vxcan
link to cross namespace boundaries at will, don't I?
Yes. This is the only reason for vxcan. All the other CAN stuff (real,
virtual, sockets, can-gw) is always labeled with only one namespace.
I'm getting a bit confused now. I'll have to run some more experiments.
My understanding is that to connect N distinctly namespace'd (v)can
together, i need vxcan and cangw. cangw running in yet another
(possibly root) namespace.
You are trying to have a common vcan instance available in multiple
namespaces, right?
The problem is:
can's and vcan's are available in ONE namespace only
vxcan's endpoints are visible in exactly TWO namespaces
Currently having multiple can-gw rules (in the root namespace)
interconnecting vxcan instances pointing into different namespaces seems
to be the only solution.
If you only have ONE CAN application in your namespace you might also
let your application use the vxcan directly (without a can-gw
crossrouting the traffic to another 'namespace local' vcan).
The vxcan has no local echo. But if you only have one application nobody
cares about the missing echo, right? ;-)
Does that fit you use-case?
To my surprised, it just worked! The biggest surprise was that docker
didn't complain about the non-IP nature of vxcan network interfaces.
Good to know. I've done nothing with Docker so far - but I know about some
colleagues that are thinking about a similar test setup too.
I would be interesting to talk with other people looking toward similar goals.
I have found a way to create a more user friendly 'experience' when it
comes to docker plugins. I can now install it with:
$ docker plugin create chgans/can4docker ...
$ docker plugin enable chgans/can4docker
$ docker network create -d chgans/can4docker ....
The plugin is not yet published, but AFAIU, it should be straight
forward to push it to docker store:
$ docker plugin push chgans/can4docker
In which case, end-users will be able to do:
$ docker plugin install chgans/can4docker ...
$ docker plugin enable chgans/can4docker
$ docker network create -d chgans/can4docker ...
My approach so far was to manually deploy and start the plugin
locally, but apparently, "native" plugins are just a sort of
degenerated docker image.
Ooookaay - did not understand the details o_O
But looking forward to the next steps anyway ;-)
Best,
Oliver
