[Tracking Issue] Implement Integraion Tests

[YJDoc2]

As per #56 , we are porting the OCI validation tests into rust. This is the tracking issue for the same.
The folder /youki_integration_test contains the currently implemented tests which are lifecyle, creation and huge_tlb

Here is the documentation for developing the integration tests:
https://youki-dev.github.io/youki/developer/e2e/rust_oci_test.html

Please only work at one test at a time, and wait for its PR to get merged before opening another one. It helps us to have an easier way for reviewing the PRs 🙏

Default

List of all test, as per https://github.com/opencontainers/runtime-tools/tree/master/validation :

• config_updates_without_affect
  • Original test code in Go: https://github.com/opencontainers/runtime-tools/blob/master/validation/config_updates_without_affect/config_updates_without_affect.go
• create(@sivchari )
  • Original test code in Go: https://github.com/opencontainers/runtime-tools/blob/master/validation/create/create.go
• default
  • Original test code in Go: https://github.com/opencontainers/runtime-tools/blob/master/validation/default/default.go
• delete (@sou1118 ) Add delete test #3082
• delete_only_create_resources
• delete_resources
• hooks
• hooks_stdin
• hostname(@chermehdi)
• kill (@YamasouA add kill test #2996)
• kill_no_effect(@oneplus1000 Added new test "kill no effect" #3332)
• killsig (@YamasouA )
• linux_cgroups_blkio(Add Cgroup V1 block IO integration test #537)
• linux_cgroups_cpus(Integration test linux cgroups cpus #462)
• linux_cgroups_devices ( @sat0ken )
• linux_cgroups_hugetlb
• linux_cgroups_memory(cgroups v1 memory integration test #473)
• linux_cgroups_network(Integration test: cgroup v1 network tests, fix to memory tests #516)
• linux_cgroups_pids(Cgroup v1 pid integration tests #391)
• linux_cgroups_relative_blkio
• linux_cgroups_relative_cpus // Please take over from Integration test: cgroup v1 relative-cpus tests #2898
• linux_cgroups_relative_devices (@sat0ken )
• linux_cgroups_relative_hugetlb(@kmpzr)
• linux_cgroups_relative_memory(@omprakaash)
• linux_cgroups_relative_network (@moz-sec Add a relative_network_cgroups test as one of the integration tests #2986 )
• linux_cgroups_relative_pids(@kmpzr)
• linux_devices Add linux_devices test #2708 by @omprakaash
• linux_masked_paths (@nayuta-ai linux_masked_paths integration test #2950)
• linux_mount_label @Gekko0114
• linux_ns_itype(Add ns_itype test #389)
• linux_ns_nopath(@cody-herbst )
• linux_ns_path(@cody-herbst )
• linux_ns_path_type(@cody-herbst )
• linux_process_apparmor_profile(@HukuKaich0u)
• linux_readonly_paths (Readonly paths #582 )
• linux_rootfs_propagation (@saku3 add-test-linux_rootfs_propagation #3024 )
• linux_seccomp test(integration_test): port 'runtime-tools/validation/linux_seccomp' #2531 by @xiaoyang-sde
• linux_sysctl test(integration_test): port 'runtime-tools/validation/linux_sysctl' #2527 by @xiaoyang-sde
• linux_uid_mappings (@moz-sec Add uid_mappings test #3161)
• misc_props(@YamasouA add misc_props test #3250)
• mounts(@saku3 )
• pidfile(Add pidfile test #379)
• poststart ( @fspv Add poststart hook test #3292)
• poststart_fail (@fspv Add poststart_fail hook test #3313)
• poststop (@donkomura)
• poststop_fail(@fspv Add poststop_fail hook test #3407)
• prestart (@fspv Add prestart_fail hook test #3406
• prestart_fail (@fspv
• process ( @sat0ken Add process test  #2968 )
• process_capabilities
• process_capabilities_fail (@kazmsk add test process_capabilities_fail #3010)
• process_oom_score_adj ( @saku3 add test process_oom_score_adj #2987 )
• process_rlimits ( @sat0ken Add test process rlimits #2977)
• process_rlimits_fail ( @ntkm61027 add process rlimits fail test #3051)
• process_user ( @sat0ken Add test process user #2978)
• root_readonly_true ( @sat0ken Add test root readonly #2976)
• start
• state

Extensions

This contains tests are not in https://github.com/opencontainers/runtime-tools/tree/master/validation , or need are not satisfactory enough.

• cgroups v1
• cgroups v2

Out of these, currently only huge_tlb is ported completely. lifecycle and create tests are implemented but need much improvements, and lifecycle tests should be split into individuals as per listed above.
Please read the README of youki_integration_test to get idea for how one should go about implementing the tests, and what utils etc are available.

[YJDoc2]

Waiting for #360 , which moves test_framework into youki_integration_test, but other than that , ready for individual test claiming.

[utam0k]

@YJDoc2 That's great! It would be a good idea to add a link to the sample implementation you implemented to the description of this issue.

[tsturzl]

I'll have some free time soon and I'd love to pitch in on this effort! I think this tooling will be a force multiplier and I think it's really impactful. Are there any pain points that I could tackle that anyone can think of that might not be a good first issue? Otherwise I'm more than happy to just jump in on cgroups controllers where I'm pretty familiar.

[YJDoc2]

Hey @tsturzl , sorry for late reply. Currently there are no obvious pain points that I know, and as you are already familiar with cgroups, it'd be great if you can work on those tests. Also if you take any test from the first list (which oci-tools have) please comment here, so we can keep track.

@utam0k I am a bit busy for few days, but after that I'm planning to work on either pid test or ns_itype test as currently both fail for runc and youki using oci-tests. Assuming that the issue is in test implementation, and not in the runtime, if we could support those tests, we can theoretically be feature equivalent with oci-tests.

[WormOn]

@utam0k i want to implement "config_updates_without_affect"

[utam0k]

@utam0k i want to implement "config_updates_without_affect"

@WormOn
Sure. I assigned you.

[tsturzl]

I'll start off with linux_cgroups_cpus, I think it will be an easy one to start off with.

[Furisto]

I do not want to take too many good first issues away, but I would like to implement at least one test to get familiar with the test framework. So I would take linux_cgroups_pids if that is alright.

[YJDoc2]

Hey @Furisto
Sure, that'd be great!