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.

[cyphar]

Having ocitools export generation as a library is a good thing for external reuse in general, and oci-image-spec reuse in particular

I have no problem with exporting a library (this is something I've been saying we need to do more of!). But why is the implication that either we have to have 50 independent libraries as separate projects, or we can't have libraries?

Personally, I'd rather take this a step farther and split runtime-spec generation, config validation, and runtime validation into separate projects.

Are you sure you're trying to help maintainers with that suggesdtion? We don't need to have 3 separate projects, that will spread resources far too thinly with no added benefit IMO. While I don't like the choice of Go (especially since you can't FFI it, meaning that C runtimes have to implement everything from scratch), we've made that decision already and we're going to stick to it.

[wking]

On Sat, Aug 20, 2016 at 08:06:03PM -0700, Aleksa Sarai wrote:

Having ocitools export generation as a library is a good thing for
external reuse in general, and oci-image-spec reuse in particular

I have no problem with exporting a library (this is something I've
been saying we need to do more of!). But why is the implication that
either we have to have 50 independent libraries as separate
projects, or we can't have libraries?

I was trying to say “If ocitools provides a generation library, what
more do you gain by putting oci-image-tool in the same repo?”. I
still don't see any benefit. I wasn't trying to say “we can't have
libraries” (I am in favor of libraries). And I don't see 50 libraries
at the moment (I see three inside ocitools, and probably those same
three in oci-image-spec, so a total of 6 OCI libraries ;).

Personally, I'd rather take this a step farther and split
runtime-spec generation, config validation, and runtime validation
into separate projects.

Are you sure you're trying to help maintainers with that?

I'm very happy to help contribute to all of these spec-tooling
projects (as I think my track record for ocitools and oci-image-spec
makes clear). I really don't see a big cost increase by splitting
repositories. All the GitHub notifications still show up in my inbox,
and I just cd into the appropriate repo to work up or review a PR.
Can you clarify where you see an increased workload due to a split?

We don't need to have 3 separate projects, that will spread
resources far too thinly with no added benefit IMO. While I don't
like the choice of Go (especially since you can't FFI it, meaning
that C runtimes have to implement everything from scratch), we've
made that decision already and we're going to stick to it.

We currently have 624 lines in cmd/ocitools/validate.go and 711 lines
in oci-runtime-config-validator's test/ (#98). The current Go config
validation has better coverage for the 1.0.0-rc1 spec, and the current
Python config validation has better coverage (>0% ;) for all other
spec versions. So I don't think we're at the point where we waste a
lot of time by switching to Python there.

And for runtime validation, I'd like to keep the Go runtimetest and
replace the current 89 lines of test_runtime.sh with sharness, bats,
or Python. Again, I don't think 89 lines is “past the point of no
return”, and it's not even Go. The only Go runtime test harness work
I'm aware of is in #61, which was last touched in May.

I understand that switching languages is not something to be done
lightly, and I wasn't very excited about the Docker distribution
project switching from Python to Go. But Go is probably a better tool
for a distribution server, just like any language with a test harness
you can install seems like a better tool for a configuration/runtime
test harness ;).

[wking]

And again (in case my preference for more, smaller repos is too
distracting), I'm ok with keeping the runtime tools together in one
repo 1.

[wking]

With opencontainers/tob#18 adopted, we can close this issue.

[liangchenye]

close since we keep this tool here :)