Add simple scripts to allow running of tutorials in a repeatable dock…

[savagesmc]

…er container.

[rjmccabe3701]

where do u use this?

[savagesmc]

You can't change the /etc/hosts file while building the docker image - you have to do from within the container - so i just made a script to add the hosts to the /etc/host file for me.

[savagesmc]

I took Steven's advice below and added the nodes in the docker-compose yaml file via the extra_hosts property.

[sgalgano]

I think this is a great contribution.

We use git flow workflow to manage our projects, so all pulls have to target develop not master. Please reissue your pull for develop.

I have a couple of questions/thoughts.

Can you place all docker files in a new emane-tutorial/docker directory:

• Dockerfile.emane
• Dockerfile.emane-tutorial
• docker-compose.yml
• make_nodes

Is make_nodes necessary? Can you set up extra_hosts in the yaml?

In Dockerfile.emane there seems to be some python3 packages installed, python3-protobuf and python3-lxml, but python3-emane is not built (WITHOUT_PYTHON3=1). Are these installs necessary? And numpy, pandas and matplotlib are not required for the demo.

Dockerfile.emane-tutorial is missing the OpenTestPoint probes used in the tutorial: opentestpoint-probe-emane.

Why is it necessary to build lxc from source?

This produces a very large docker image. As an alternative to installing a complete build environment, we have a prebuilt package bundle for 16.04. While it is not exactly a PPA, it has everything you need built, tested and signed. Well almost everything, pynodestatviz is not in the bundle. Unpacking the bundle and installing as part of the Dockerfiles would reduce the footprint of the resulting image and speed up build time. You don't need to install any of the dev packages.

Additionally, this does not have to be part of the emane-tutorial project. You can just as easily clone the tutorial from github as part of making the image. And you can have an emane-tutorial-docker project that consists of the dockerfiles and yaml. If you decided to do that we would link to your project from the tutorial Wiki. I leave that choice to you, since that would imply you would be the maintainer.

[savagesmc]

Steven, I have addressed most of your comments, and pushed another version for you to look at. I have reduced the size of the image quite a bit now with this version. Also, the reason I had to build and install lxc, was because the emane-tutorial doesn't work with the version 2 family of lxc for some reason, but it still works with version 1.0.11 at least. There was an lxc bug fix that a colleague of mine here at Rockwell Collins submitted to lxc last fall that is needed, and I know that 1.0.11 has this incorporated. As to putting the dockerfiles into their own container, I preferred to leave them here, as I saw this docker capability being used in the future to perform some continuous integration type services on emane. I may work at adding some automated tests in the future given my free time and availability. Thanks!

[sgalgano]

I changed the pull target to the develop branch. We use gitflow workflow for our open source projects.

[savagesmc]

Sorry about that. I moved over to the gitflow workflow. I also changed the dockerfiles to use the develop branch for both emane and the emane-tutorial when building.

[sgalgano]

There is a typo in READ.md: s/docker-compoe/docker-compose

docker-compoe run emane-tutorial /bin/bash

It would be helpful to set up a script that runs on first boot (which would be always unless filesystem changes are committed) to allow passwordless ssh access to the lxc nodes.

Something like the below is what happens on first boot of the Tutorial VM:

ssh-keygen -P "" -f /root/.ssh/id_rsa
mv /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys

You can reduce login noise by changing/replacing/removing the message of the day that appears when sshing into an lxc node.

I'm still on the fence about building packages instead of installing them. The emane-tutorial target audience is pretty wide and we use the tutorial as part of our training courses. A slimmer docker image that builds faster and only contains a runtime environment would match the Tutorial VM philosophy. I can see the benefit of having a docker image that builds from source for certain purposes, just not the tutorial.

With that said, using emane:develop may make sense for continuous integration but it will not work for the general audience. There is no guarantee that emane:develop will work with the tutorial. The latest releases of emane:master and emane-tutorial:master will always work together, but that is where the guarantee ends. For both projects, feature branches are regression tested prior to merging into develop, but the development in one is not necessarily related to the other. For example, adding a new demonstration to the tutorial that works with emane:master but will require changes once emane:develop is merged.

Along those lines, I think it is better to install the emane-tutorial via a git clone rather than copy it in. Just now I ended up building an image using a local branch of the tutorial I had checked out, which was not my intention.

You can add docker-compose build argument options (--build-arg) and set the images to build for master by default but allow changing that to any branch for either project. This will give you finer
control but work in the general case for others.

As far as lxc, we have been running the tutorial and other projects that similarly use containers on 16.04 with the latest repo release (2.0.7) without issue.

What is the procedure/mechanism for being able to run olsrlinkview.py? Currently that is the only gui application used during the tutorial.

[savagesmc]

I finally got back to this after many months. I'm actually working on a new emane model now, so wanted to be able to use your tutorial again to figure some stuff out. Anyway, I think I've incorporated most of your comments on the previous post. I changed emane to simply install via your pre-built ubuntu image. I incorporated your ssh snippet above to simplify loggin into the lxc containers, and I added x11-common and sshd setup so that you can 'ssh -YC' into the tutorial docker container and forward your olsrlinkvierwer.py x-windows output to your display. Are there any other things that you have thought of since we worked on this previously? The container is 1.13 GB, about 30% larger than your VM, so maybe it's not really useful anyway.