Discuss ocitools moving into the runtime-spec repo

[caniszczyk]

We should have a discussion whether it makes sense to move ocitools into the runtime-spec repo. As a plus, it would give the tools more visibility and make it easier to keep in sync with the runtime-spec. It would also potentially simplify the project structure by merging it into one project (instead of having two)

FYI: the tooling for testing the image-spec currently lives in the same repo:
https://github.com/opencontainers/image-spec/tree/master/cmd/oci-image-tool

[philips]

I think we should move it and have it versioned. @mrunalp can we add it to the agenda for tomorrow?

[wking]

On Tue, May 31, 2016 at 05:33:16PM -0700, Chris Aniszczyk wrote:

As a plus, it would give the tools more visibility…

There's already visibility via 1.

… and make it easier to keep in sync with the runtime-spec.

Syncing per-release doesn't seem like a big cost. And separate
repositories make it easier to have a single validator that supports
several versions of the runtime spec (e.g. it could validate both v1.0
and v1.1).

It would also potentially simplify the project structure by merging
it into one project (instead of having two)

Certification is discussed independently in the charter 2, and only
@mrunalp is in both maintainer sets at the moment (although the
ocitools maintainer set is small ;). Do you really expect a lot of
overlap here? I expect lots of folks will be interested in having
their platform and/or use-case supported in the spec, but only a few
folks will be interested in writing the tooling to certify compliance
;).

[caniszczyk]

Would love to hear more from the @opencontainers/runtime-spec-maintainers on this

[vbatts]

I voted from the beginning for the tools to be inside the specs repo.
The pros are easier lock-step versioning.
The cons are more churn that is not specific to the specification itself, and possibly having tool-specific maintainers.

[vishh]

We can solve the maintainers issue using labels. We can have tool-specific
maintainers apply a label like lgtm and have the spec maintainers merge
those PRs.

On Wed, Jun 1, 2016 at 11:19 AM, Vincent Batts notifications@github.com
wrote:

I voted from the beginning for the tools to be inside the specs repo.
The pros are easier lock-step versioning.
The cons are more churn that is not specific to the specification itself,
and possibly having tool-specific maintainers.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#83 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGvIKKnlsQBmGDT0u8JpbRtH52O3lBZ-ks5qHc1HgaJpZM4IrFXr
.

[caniszczyk]

My preference would be to have the @opencontainers/runtime-spec-maintainers reach consensus (or vote if need be). It would also make sense to mirror what the image-spec is doing for consistentcy purposes IMHO

[wking]

On Wed, Jun 01, 2016 at 01:05:46PM -0700, Chris Aniszczyk wrote:

My preference would be to have the
@opencontainers/runtime-spec-maintainers reach consensus (or vote if
need be). It would also make sense to mirror what the image-spec is
doing for consistentcy purposes IMHO

The arguments should not be runtime/image-specific, but that doesn't
mean the different maintainer sets come to same conclusions based on
those arguments ;).

[cyphar]

@caniszczyk There is a question about whether or not we'll end up having ocitools do some operations related to image-spec? Or are we going to create an entirely separate set of tools for that? I personally like the idea of ocitools -- everything you need to generate all things OCI.

[wking]

On Wed, Jun 01, 2016 at 09:28:51PM -0700, Aleksa Sarai wrote:

There is a question about whether or not we'll end up having
ocitools do some operations related to image-spec? Or are we
going to create an entirely separate set of tools for that?

There is already an entirely separate tool for that (linked from this
issue's topic post 1).

[wking]

Cross-linking recent discussion:

• @cyphar asked whether we're planning on consolidating non-spec OCI
  tooling in ocitools (vs. the initial proposal in this issue to move
  ocitools into runtime-spec) earlier in this thread 1 and then
  again on the list 2.
• In this last meeting 3, @RobDolinMS recommended separate repos for
  specs and tools, and revived his proposal to make ocitools and
  similar *-tools repos formal OCI Projects [4](initially floated in
  [5]). @vbatts pointed out the benefit of separate repos for
  decoupled versioning and making it easier for a single tool version
  to cover multiple spec versions (see also Use Python's unittest for validating bundles and configurations? #98 on this point). And a
  few others (including me) +1ed the idea of separating specs and
  tools.

The meeting notes didn't really get at @cyphar's question, with the
following two choices up in the air:

a. A single ocitools covering image-spec and runtime-spec.
b. Pulling oci-image-tool out into an image-tools repo (following
@RobDolinMS's naming 4) and renaming ocitools to
[oci-]runtime-tools.

I'm personally in favor of (b), because there's enough going on in the
each spec's tooling by itself, and the overlap in tool maintainer sets
doesn't seem large.

 Subject: Re: Agenda for 8/17
 Date: Wed, 17 Aug 2016 13:29:29 +1000
 Message-ID: <CAOviyairNCoozpwg3eKtwP-7K03TZcSgvbGyG_AhMrFoXbPOtg@mail.gmail.com>



 Subject: RE: Agenda for 6/15
 Date: Wed, 15 Jun 2016 16:37:29 +0000
 Message-ID: <BY2PR0301MB1608A853DF9ABEA5BA2084CADE550@BY2PR0301MB1608.namprd03.prod.outlook.com>

[hqhq]

a. A single ocitools covering image-spec and runtime-spec.
b. Pulling oci-image-tool out into an image-tools repo (following
@RobDolinMS's naming [4]) and renaming ocitools to
[oci-]runtime-tools.

I think we all can see the pros can cons about merging or separating them, I'll vote for b and I think the reason would be similar with why we separate image-spec and runtime-spec in the first place.

[cyphar]

While I see the argument for b, the image-spec requires you to have a runtime-spec configuration in the images. So they're very tightly linked, and any image tooling that doesn't include ocitools level of configuration for the runtime-spec isn't going to be very useful.

Yes, I get that you could manually join the two together but then you have an interdependency between two tools. Since we're planning on maintaining both sets of tools anyway why not consolidate them?

Overall however, I am in favour of any proposal where we move any and all tooling out of the -spec repos.

[wking]

On Sat, Aug 20, 2016 at 03:00:22AM -0700, Aleksa Sarai wrote:

While I see the argument for b, the image-spec requires you to have
a runtime-spec configuration in the images. So they're very tightly
linked, and any image tooling that doesn't include ocitools level
of configuration for the runtime-spec isn't going to be very useful.

Currently, the only coupling I see is with the configuration
conversion (opencontainer/image-spec#87). My peferred solution to
that is to have image-spec get out of the runtime config business (all
of my comments in opencontainer/image-spec#87) and focus on moving
opaque directories around efficiently and securely. Even with the
config conversion, the overlap between the two toolsets doesn't seem
particularly strong, especially now that ocitools exposes config
generation as a library (since #131). So I don't see how
oci-image-tool suffers by not being compiled into ocitools.

Yes, I get that you could manually join the two together but then
you have an interdependency between two tools. Since we're planning
on maintaining both sets of tools anyway why not consolidate them?

Having ocitools export generation as a library is a good thing for
external reuse in general, and oci-image-spec reuse in particular
(assuming image-spec stays in the config-translation business).
Dependencies are usually a good thing, because they allow the
individual components to focus on doing a small number of things well,
and make it more likely to have stable, well-documented interfaces
between different layers of the composite system. So if the system
naturally decomposes into subsystems, I'd rather have each subsystem
as a separate project/repository.

A set of small, focused projects also makes life easier for downstream
consumers that want to use some of the OCI functionality, but don't
feel comfortable pulling in the whole OCI toolset. We had the same
issue with Docker, where we wanted access to a generic mount utility
package without pulling in all of Docker and ended up forking it 1.
That's an unfortunate solution, and I'd much rather not force a
similar choice on OCI consumers.

Personally, I'd rather take this a step farther and split runtime-spec
generation, config validation, and runtime validation into separate
projects. That makes it more likely that maintainers pick the best
tooling for the task at hand 3, instead of trying to wedge
everything into Go because it's a good choice for
inside-the-container, statically-linked checkers. But the ties
between the runtime tools are (and should be) stronger than the ties
between the image tools, so I understand if folks want to keep the
various runtime tools collected under a single project/repo.

Overall however, I am in favour of any proposal where we move any
and all tooling out of the -spec repos.

I agree that both (a) and (b) (from 3) are better than keeping
oci-image-tool inside the image-spec repo.