[Tracker] Support standard validation and defaulting

[vishh]

As of now, the Spec does not explicitly state the fields that are required. This can lead to various implementations of the Spec defaulting and validating the Spec in its own manner.
Annotating each field in the Spec with a required or optional tag along with the default value will help with readability. But it does not ensure conformance.
To provide a seamless experience with OCI bundles across various implementations of the Spec, we should provide standard validation and defaulting tools. These tools might have to be platform or OS specific.

Largely happening in https://github.com/opencontainers/ocitools

Goals:
[ ] configuration validation
[ ] environment testing

[vishh]

@mrunalp: Are you working on this already?

[mrunalp]

@vishh I have a spec generation tool at https://github.com/mrunalp/ocitools
Some validation work is also in progress there.

[liangchenye]

@mrunalp , what is the plan of the OCI tools?

1. repo
   Create an official spec repo or merge from an outside one?
   You, Kunal and we (OCT folks) are working on the similar thing now.
2. scope
   generator, bundleValidator, runtimeValidator.
   And more tools like 'convert'?
   (https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/OHlbEfHUaiA)

[zenlint]

@mrunalp @vishh,
I and my team were working hard at the runtimeValidator(https://github.com/huawei-openlab/oct/blob/master/tools/runtimeValidator/README.md) and bundleValidator(https://github.com/huawei-openlab/oct/blob/master/tools/bundleValidator/README.md), and they are working well now.
Maybe the idea is not highly consistent with your's, but I think it is not necessary to develop a Validator from the very begining. We could disscuss them together, and economize the existing project.

Thanks, expect to your Directive opinion.

@liangchenye，
I suggest to have a repo like 'https://github.com/opencontainers/oct' or 'https://github.com/opencontainers/ocitool'.

[mrunalp]

@liangchenye @zenlinTechnofreak Could you guys give a demo and walk through of what
you have implemented? I went through the documents but it did not seem to work for me. (It must be something I am doing wrong).

[liangchenye]

Hi @mrunalp,
Seems our document is still not clear enough :(
Now we have 4 tools in 3 independent directories.

• Config Generator & Bundle Validator
  Similar with your project.
• Runtime Validator
  More test cases included, testing if 'runc' works as expected.
• Convert: aci2oci
  In order to have more 'meaningful' OCI bundle, not just demos.

Thank you for your time.
David Liang

[vbatts]

conversion tools, while needed will be external tooling. They will be many and potentially needing independent ownership. Besides format conversion, I'm imagining oci2nspawn or oci2lxc for execution of opencontainer bundles. Let's just have a wiki page for these kinds of external tools.

[wking]

On Fri, Oct 16, 2015 at 12:01:22PM -0700, Vincent Batts wrote:

Let's just have a wiki page for these kinds of external tools.

Couldn't we list them in a section of our implementation listing 1?
At this early stage, it seems like the more visible mass there is
around OCI, the better (and to me 1 seems more visible than the
wiki).

[vbatts]

Some amount of validation will be provided through #313 as well

[philips]

What are the tactical things that need to be done here now. @vbatts says some stuff is now covered but what is left for someone to do?

[wking]

On Thu, Jun 02, 2016 at 09:36:15PM -0700, Brandon Philips wrote:

What are the tactical things that need to be done here now.

I'm not clear on the summary's “defaulting”, but I think that between
this repo's existing JSON Schema and ocitools (see
opencontainers/runtime-tools#66) we can close this issue.

[mrunalp]

@philips We can close this one given what we have in ocitools and the schema as @wking pointed out.

[crosbymichael]

Yep, this can be closed because of ocitools and the schema work that has been done