add mount validation function in runtimetest

[wangkirin]

Signed-off-by: Wang Qilin qilin.wang@huawei.com

[wking]

I think this approach may be too simplistic.

• It doesn't handle the required mounts from config-linux: specify the default devices/filesystems available runtime-spec#164.
• By the time you're inside the container checking the host-side source is difficult (although a Btrfs pivot-root entry has subvol=${HOST_PATH_TO_PIVOT_ROOT}, so maybe it's not impossible).

Instead of writing something that generically validates any bundle's mounts, it's probably easier and effective enough to write a few bundles that make specific mounts and then check for those after launching the bundle (e.g. does the container's /file match the bundle's roofs/file? Is / read-only or not? …).

[wangkirin]

@wking thank you for your advice!

1. about required mounts check, I think it's more appropriate to finish it in bunlde validator , not in runtime test. That means if you do not load these required mounts, your bundle is considered illegal
2. I agree with your idea about not validating any bundle's mounts, but there is a problem that in current testing framework , we use a single bundle to test all specs items , so we need to cover the restrictions defined in specs, like type in mounts [1]

[1]https://github.com/opencontainers/specs/blob/master/runtime-config.md

[wking]

On Mon, Jan 25, 2016 at 03:18:48AM -0800, Wang Qilin wrote:

1. about required mounts check, I think it's more appropriate to
   finish it in bunlde validator , not in runtime test. That means if
   you do not load these required mounts, your bundle is considered
   illegal

As I read opencontainers/runtime-spec#164, the runtime must supply those
mounts regardless of the user config (unless we specify an opt-out
mechanism, which we don't have yet). So it's a runtime-author problem
(not a bundle-author problem) if they're missing.

1. I agree with your idea about not validating any bundle's mounts,
   but there is a problem that in current testing framework , we use a
   single bundle to test all specs items , so we need to cover the
   restrictions defined in specs, like type in mounts [1]

It doesn't seem possible to test different config permutations with a
single bundle. You could probably do it with a single rootfs and a
bunch of per-test configs (which was how I understood this repository
to work). If setting up a bundle to bind-mount a file from the host
into the container is too difficult to do, we should probably adjust
ocitools to make it easier ;).

[zenlint]

@wking @wangkirin
To [1],
When we test runtime's compliace, the input is the bundles, output is the runtime can have the behavior we expected or not with the input. So, agree with @wking

To [2],
That is what we need to do in ocitools, actually, we should have a scheduler and a cases manager in ocitools runtimetest/validate command.

A scheduler is whom to schedule the cases(input as bundles here).

A cases manager to manage cases, like TestUnit in PR "Add initial version of runtimetest command: #9". Through adding some elements into cases manger(like TestUnit), scheduler can easily schedule bundles to run on the platform/machine required.

Anyway, let us do effort step by step to reach the destination.

[Mashimiao]

I think this PR can be closed. as #81 make detailed validation

[mrunalp]

Closing as we merged #81