The OCT project aims to promote the Open Container Initiative by providing a universal open container testing libs
or tools
.
Following the OCI Principles:
Define a unit of software delivery called a Standard Container.
The goal of a Standard Container is to encapsulate a software component
and all its dependencies in a format that is self-describing and portable,
so that any compliant runtime can run it without extra dependencies,
regardless of the underlying machine and the contents of the container.
OCT covers following areas:
###Standard Container Test A standard container should be a bundle with one standard 'config.json', one standard 'runtime.json' and one standard 'rootfs'.
OCT provides Bundle Validator to verify if a bundle was a standard container.
###Compliant Runtime Test
OCT provides Runtime Validator to verify if a runtime was a compliant container.
The Runtime Validator
has four components:
- Test Cases
TheTest Cases
define a 'target' and a list of 'tests'. The 'target' is a single configuartion, the case developer could fill the 'tests' part with different values to cover more/all testing.
#rootfs readonly test
readonly.json
{
"Target": "spec.root.readonly",
"Tests": [
{"value": true},
{"value": false"}
]
}
- Standard Testing Containers
TheStandard Testing Containers
are the standard containers with different configurations in order to cover all the aspects of runtime test. The config.json/runtime.json in these containers are coming fromTest Cases
by OCI generator. After being verified by the Bundle Validator, all these containers became theStandard Testing Containers
- Runtime Validator Program
TheRuntime Validator Program
runs inside a runtime to verify if settings mentioned in config.json and runtime.json match the relevant system information. - Runtime Validator Manager
TheRuntime Validator Manager
loads all theStandard Testing Containers
, usesRuntime Validator Unit
to verify if a runtime runs all theStandard Testing Containers
correctly.
####Compliant Runtime Testing Flow There are two types of runtime, the first type support image with OCI format (Standard Container), the second type only support image with other format. Both of them could be 'OCI compliant', only difference is the second type need a 'conversion' phase.
####Flow Chart Two - begin with Standard Testing Containers
###Generator tools
OCI generator - generate config.json/runtime.json from Test Case
.
###Conversion tools One implementaion of converting from OCI to ACI is hosted at: oci2aci
###Other tools To make OCT easier, more tools are required:
- OCI builder - build a native OCI bundle
- OCI convert - convert from other images, like rkt.
- Fork the repository on GitHub
- Read the 'build and test instruction' for Bundle Validator and Runtime Validator
- Play with the project, submit bugs, submit patches!
If any issues are encountered while using the oct project, several avenues are available for support:
Issue Tracker | https://github.com/huawei-openlab/oct/issues |
---|---|
Google Groups | https://groups.google.com/forum/#!forum/oci-testing |
- Open Container project developer/user
The engine
part is now moved to oct-engine