Failed Build of Docker File: CMake Error

[mc-2021]

Hello,

We are trying to build an image of Artery/Sumo/OMNeT++ on Docker We used your DockerFile but we obtain the following error: CMake Error: The source directory "/artery/source" does not appear to contain CMakeLists.txt. Could you please explain the source of the error?

Thank you

[riebl]

Hi @mc-2021,

/artery/source within the container is expected to be equal to the content of your local working copy of the Artery repository, i.e. the directory where the Dockerfile itself is located. I have just rebuilt the Artery container without problems using docker build -t artery:latest . I suppose you have used another build context and thus the Artery repository is missing, have you?

[mc-2021]

Hello, Thank you for your answer. We tried first to edit the dockerfile to install our own image (ubuntu, different omnet, sumo versions , and dependencies). However even by downloading this repository (artery-master) and using the provided dockerfile with no modifications, we get the same error:

Shall we create a source directory ? We think the problem starts when COPY . /artery/source. Could you please give us more guidance on how to copy this from where to where (host to container?)

Thank you,

[riebl]

Yes, the line COPY . /artery/source seems to behave differently in your case. It copies basically everything from the Docker build context to /artery/source in the container image. I run docker build -t artery:latest . from Artery's root directory, so the whole Artery repository is copied to /artery/source, including the CMakeLists.txt file. You may want to check the actual content of /artery/source in your case.

[mc-2021]

Hello, Thanks for the answer. It works fine now. It seems that our first artery directory downloaded was not complete. However after a successful build we couldn't run the image. Here below the command and error message Error message Successfully built 4debc3a969b3 Successfully tagged artery:latest root@araceli-Latitude-5590:/home/avp/Projects/DockerTutorial/artery# docker run --name artery -v /home/ubuntu/artery/scenarios/artery:/scenario -v /home/ubuntu/artery/results:/results artery:latest -c inet OMNeT++ Discrete Event Simulation (C) 1992-2019 Andras Varga, OpenSim Ltd. Version: 5.6.2, build: 200518-aa79d0918f, edition: Academic Public License -- NOT FOR COMMERCIAL USE See the license for distribution terms and warranty disclaimer End. <!> Error: Cannot open ini file 'omnetpp.ini'

Thank you in advance!

[riebl]

Most likely something went wrong when binding the volumes to the container, i.e. /scenario/omnetpp.ini does not exist in the container. You may examine your container's filesystem via docker run -it --name artery -v /home/ubuntu/artery/scenarios/artery:/scenario -v /home/ubuntu/artery/results:/results --entrypoint /bin/bash artery:latest which will give you a shell instead of starting a simulation run.

[mc-2021]

Hello, Indeed, we run this command and we checked the different directories here attached the description

The scenario directory is empty

I think, we are missing many other files, for example no include directory in omnetpp as well:

Shall we rebuild the image or try other version or OS (ubuntu)?

Thank you

[riebl]

The OMNeT++ include directory is not copied to the final container image, so it is expected that you have only /omnetpp/bin and /omnetpp/lib. That your /scenario directory is empty means that no volume has been mounted there properly. In your case, you bind /home/ubuntu/artery/scenarios/artery: Is this directory on your host empty as well?

[mc-2021]

/home/ubuntu/artery/scenarios/artery is not empty on our host.

[riebl]

To be honest, I don't know why /scenario is then empty in your container.

[mc-2021]

We succeeded to build and run the image (path problem), the new error we are getting is: we tried to copy the Erlangen SUMO scenario copied into /scenario and accordingly adjusted omnetpp.ini.
However we can't copy the files unless we run the container (because we need container ID)
and we can't run the container unless we have the example copied

should we copy these while building the image? Thank you!

[riebl]

I suggest creating self-contained scenarios when using Docker, i.e. where all files are located in the same directory. The container image is expected to be generic and thus independent of the actual scenario.

For example: Copy content of scenarios/artery to docker-scenario, change the *traci.launcher.sumocfg line in omnetpp.ini to erlangen.sumo.cfg (without relative path), copy the required erlangen.* files from externs/veins/examples/veins also to docker-scenario. In the end, the scenario configuration in docker-scenario does not refer to any files outside this directory. Run the container then docker run ... -v/path/to/docker-scenario:/scenario.

[mc-2021]

Hello, Thank you again for your interactive answers. We did the following (the order is important): 1-Build the docker image with the existing dockerfile: docker build artery:latest . 2-Create a container with this image in order to have a container ID (for copy later): docker create --name aos artery:latest 3- copy all content of our host file artery/scenarios and extern/veins/examples/veins/ to container:/scenario: (eg) docker cp pathto/artery/scenarios/artery/service-envmods.xml 7c684774633e:/scenario 4- modify *traci.launcher.sumocfg line in omnetpp.ini to erlangen.sumo.cfg (without relative path), then copy it to container/scenario 5- Now we start the docker container with docker start -ai container ID we obtain this error

We think it is a problem of docker commands order rather than simulation files. We need the run command in order to precise the volumes and -c inet, however we need to copy first the files into this container. We are new to docker ^^ Do you have a suggestion ? Thanks in advance! .

[riebl]

I do not consider myself a Docker expert either. As far as I know, manually editing container images is not a good practice. At least, this results in container images that are hard to reproduce.

I think it makes sense to get a bundled scenario running first and deal with problems arising with a custom scenario afterwards. Can you reproduce the following steps successfully?

cd /path/to/artery/repository
docker build -t artery:latest .
docker run --rm -v $PWD/scenarios/storyboard:/scenario artery:latest

[mc-2021]

Done and same error

[mc-2021]

Same with the first scenario:

[riebl]

Okay, we can deal with that permissions issue. I have just pushed a commit which causes SUMO log files to be written to the result directory instead of the scenario directory. Hence, I can even bind the scenario directory as read-only filesystem to the container: docker run --rm -v $PWD/scenarios/storyboard:/scenario:ro artery:latest I think log files belong to the result directory anyway.

[mc-2021]

same error, but at some point it displays demo.py successfully imported

[riebl]

Have you really rebuilt the container?

[mc-2021]

I deleted all exisitng containers and run a new one with the provided command. I did not rebuilt the image because i did not modify the dockerfile. Maybe i did not get ypur previous answer " have just pushed a commit which causes SUMO log files to be written to the result directory instead of the scenario directory. Hence, I can even bind the scenario directory as read-only filesystem to the container: docker run --rm -v $PWD/scenarios/storyboard:/scenario:ro artery:latest". Could you please give further details. Thank you for your collaboration. Regards

[riebl]

Pull the latest update via git and then you need to rebuild (partially) the container image so it reflects the updated sources. docker build detects that the build context, i.e. your working copy of the Artery repository, has changed and will compile them again. At least that is what happens on my system.

[mc-2021]

I just figure out that there were some recent modifications on the git repository (src directory), i cloned the new one on my host and i'm rebuilding the image. Thank you for all this guidance. We will keep you posted about the final result :)

[mc-2021]

Finally it worked! Thank you very much :)

[riebl]

I am happy to hear that you have got it up running now. I will close this issue ticket then. Feel free to open a new ticket when you face another problem.

[Enough7]

For some reason the omnetpp.ini is in my container's directory /scenario but it seems Omnet++ expects it to be in /omnetpp.

<!> Error: Cannot open ini file 'omnetpp.ini'