Add convert tools as the sub command of ocitools

[zenlint]

If ocitools want to support different runtimes, there are two steps are needed.

1. wrappers to CLI, thus, ocitools runtimetest can call the runtime with the uniform API.
2. convert tools, similar to oci2aci.

we can disscuss the 1st in issuse "Initial code of runtimetest command #10".
And this topic talks about where to import convert tools, one way is to import convert tool as a subCommand of ocitools, like generate.

Anyway, ocitools is like a oci tool set now.

[Mashimiao]

+1
Adding convert tools as the sub command of ocitools, I think this is appropriate.

[wking]

On Fri, Jan 29, 2016 at 12:39:03AM -0800, LinZhinan(Zen Lin) wrote:

2 convert tools, similar to oci2aci

…

And this topic talks about where to import convert tools, one way is
to import convert tool as a subCommand of ocitools, like generate

-1 to including conversion tools in this repository, which should
focus on OCI compliance. If folks want to use separate repositories
to write wrappers around runtimes with conversion tools [1], then we
can test those wrappers for OCI compliance using this repository. But
if this repository contains the wrapper/conversion code, and the
compliance test fails, who's fault is it? Is it a bug in the
underlying engine? Is it a bug in the wrapper? It just gets
confusing.

On the other hand, with wrapper/conversion tooling in a separate
repository, maintained by folks who are familiar with both the OCI
specs and the underlying tool, the responsibility for fixing the issue
is much clearer. We just say “these tests failed”, and they go and
fix their wrapper, or the underlying engine, or they tell us we're
miss-interpreting the OCI spec.

1: #4 (comment)

[zenlint]

@wking Quite agree with u, it is nice to keep the repo's integrity.
And another concern is if we have another tool repo for wrapper/conversion, there will be a more repo for tools under opencontainers, and there may be more and more separate repos for tools under opencontainers in future , could the OCI member agree that?

[wking]

On Fri, Jan 29, 2016 at 05:18:08PM -0800, LinZhinan(Zen Lin) wrote:

… but I think it is a heavy work to ask OCI members to have another
repo for wrapper/conversion tooling…

It's lighter work here for folks who aren't interested in wrapping
that particular tool ;). For folks who are interested in wrapping a
particular tool, I don't see what you gain by maintaining the wrapper
in this repository. Having a bunch of uninterested maintainers around
is unlikely to make your life easier, and the mechanics of setting up
and managing a GitHub repo are not very difficult. Can you be more
specific about what the heavy work entails?

… under opencontainers.

I don't mind where it lives, and I don't see how that would impact
maintainer cost.

[zenlint]

@wking
yes, I got it. I also don't mind where it lives too, I write here to open a discussion just because the runtimetest have to use the wrapper and coversion tool.

[wking]

On Sun, Jan 31, 2016 at 05:20:56PM -0800, LinZhinan(Zen Lin) wrote:

yes, I got it.

Also note that this isn't my repo ;), I'm just chiming in with my
opinion in case it helps. A number of OCI maintainers seem to prefer
fewer, larger repositories.

… I write here to open a discussion just because the runtimetest
have to use the wrapper and coversion tool.

Agreed. For me, it comes down to “who will maintain the
wrapper/conversion tooling?”. Ideally, I'd like the upstream engine
to support an OCI API like [1](although I don't really care if it's
that command line interface, or even a command line interface at all,
as long as there is some standard interface). Lacking that, I'd
rather offload wrapper/conversion maintenance for a given engine to
any developers who are interested in both the engine and OCI
compliance. But I think this repository should be for
maintainers/contributors who are only interested in OCI compliance,
and in that case, building compliant wrappers around otherwise
non-compliant tools is off topic.

[wking]

This is related to #54, which adds a * -> OCI translation framework. I still think OCI -> * belongs outside this repo, and would be cautious about using the #54 framework for any moderate to complicated source spec, even if it targeted OCI.

[liangchenye]

close. When we need a framework like CRI-O, rework on this.