Acceptance test environment

[Metallion]

Finally the acceptance test environment is in a state where we can start writing proper tests. In short:

• Package acceptance test code as openvdc-acceptance-test package
• Run docker container that installs said package and builds the test environment
• Run tests
• Destroy container unless LEAVE_CONTAINER is set.

Additional change to openvdc-cli package:

• Added a symlink to the openvdc binary in /usr/bin so the openvdc command is in PATH immediately after installing.

Current tests written:

• Check if openvdc command can be run and outputs usage.

More detailed information is in the readme included in this diff.

[triggers]

Looks impressive.

Things to add:

1. What bare metal OS versions has it been run successfully on? Docker version?
2. How much disk/memory is required?
3. How long does it take to run?
4. What does successful output look like?
5. Are all the side effects kept under one directory? Where else will it put stuff?
6. Where are the most important log files?

[Metallion]

1.1. Will add to the readme. (Fedora 23 and Arch)
1.2. Will add this too. (1.10.3 on Fedora and 1.12.6 on Arch)
2. Will add.

The other items don't really need to be in the readme imo but here's the answers.

3. About 20 minutes the first time and about 5 minutes afterwards
4. https://ci.openvdc.org/job/citest/job/acceptance-test/32/console
5. Everything's in either the cache directory or the docker container. So all directories it does stuff to are in the readme.
6. It doesn't keep log files. Just the output in Jenkins.

[toros11]

Perhaps we can re-enable the feature that uses cache images for develop/master unless rebuild flag set. It would save time when building branches and unless anything happened to the CI itself there is no need to build all images from scratch.

[Metallion]

Perhaps we can re-enable the feature that uses cache images for develop/master

On my TODO list. :p #89

[unakatsuo]

Why do we need to run docker commands with sudo?

docker rpm creates dockerroot group and the UNIX users who want to operate docker command just need to join the group.

[Metallion]

Why do we need to run docker commands with sudo?

I chose to do it like that because of this: moby/moby#9976

Access to the Docker API is effectively root access. Even lacking --privileged, there are numerous mechanisms to avoid system policy if one has access to the docker socket or API.

A user being in dockerroot seems to be equivalent to that user having root access. Also we are using the --privileged flag in order to use KVM inside of the container. If we're going that far, I thought it was better to be clear that we're running with elevated rights by using sudo.

If there is a good reason not to use sudo despite this, I'm ready to learn. :)

[unakatsuo]

They provides --device and --cap-add for security control similar to lxc. We can explore them later.

[Metallion]

Yeah, I know about those. I'll make an issue to add their use later. Thanks for the review. ^_^