Suggestion: Add a Getting Started

[RobDolinMS]

It may be useful to add a how-to / getting started doc for people who may want to run the OCI Tools on a new, clean VM. (Such a process may also be useful for replicable certification results.)

Please comment and tag me back if it would be helpful for me to create a PR.

With help from @mrunalp, below are instructions that worked for me:

1. mkdir ~/gosrc (could be any directory)
2. export GOPATH=~/gosrc
3. sudo apt-get install gccgo-go
4. go get github.com/opencontainers/ocitools
5. cd ~/gosrc/src/github.com/opencontainers/ocitools
6. make
7. sudo apt-get install go-md2man
8. sudo make install

[crosbymichael]

Why gccgo? We should probably use the "real" Go.

[mrunalp]

Yeah, we should use the go package. That's what we use for development/testing, etc. The gcc-go package will be lagging in features/library support.

[RobDolinMS]

Thanks @crosbymichael and @mrunalp. Then should line #3 above be replaced with sudo apt-get install golang ?

[amitsaha]

FWIW, I think linking to the guide on golang.org may be a better idea for two reasons:

• The distribution repositories may be out-of-date
• You then have to default to a single distro or have a list of commands for different distros.

[cyphar]

Note: some architectures still aren't supported by the standard gc toolchain.

[crosbymichael]

@cyphar yes, but supporting the "real" Go in the install docs is better, if they need another arch then they will find gccgo and all that it entails.

[liangchenye]

How about add a Dockerfile to the 'contrib' directory?

[liangchenye]

It is quite easy to test if a runtime passes oci runtime validation by using travis service.
I added a .travis.yml file to my own runc project. (oci branch).
https://github.com/liangchenye/runc/pull/3
The result is quite positive and looks good: https://travis-ci.org/liangchenye/runc/builds/135002152

[wking]

On Fri, Jun 03, 2016 at 04:51:57AM -0700, 梁辰晔 (Liang Chenye) wrote:

The result is quite positive and looks good:
https://travis-ci.org/liangchenye/runc/builds/135002152

Heh, I think that means we have some holes in our tests ;). For
example, we have workarounds like #24 because runC has not implemented
features that landed in the spec before v0.1.1 (with
opencontainers/runtime-spec#164) and still exist in v1.0.0-rc1 1.

Stepping back and assuming a perfect implementation, I think this is
going to be hard to support as runtimes react to
backwards-incompatible changes landing in the spec master. In that
case, the test will fail because the runtime master isn't implementing
a valid spec release (it's moving towards a future spec release).
As the test suite gets stricter, it is more likely to pick up on that
sort of discrepancy.

So I think we want to make it easy to validate a runtime with
ocitools. But I think we should recommend it as pre-/post-release
testing, and not as part of a runtime's CI testing.

[liangchenye]

I hope every runtime could follow oci spec and use ocitools to verify that.
I checked travis, seems that it cannot test just on pre-/post-release. Maybe there are some more appropriate github services.

I was thinking of how to 'certify' a runtime, travis is not suitable. In https://github.com/kubernetes/kubernetes, there are some widgets, GoReportCard Widget GoDoc Widget Travis Widget Coverage Status Widget what do you think of
implementing an 'OCI certified widget' ? @wking

[wking]

On Mon, Jun 06, 2016 at 12:04:45AM -0700, 梁辰晔 (Liang Chenye) wrote:

I hope every runtime could follow oci spec and use ocitools to
verify that. I checked travis, seems that it cannot test just on
pre-/post-release. Maybe there are something more appropriate github
services.

I think pushing this off to the runtimes is the wrong approach. For
one thing, there's a potential conflict of interest in
self-certification. The OCI charter has a bit of wording around an
OCI “certification program” 1. I'm not sure who is involved with
that effort, or what the boundary is (if any) between that project and
the ocitools repository (general lack of clarity on projects is
currently tracked in opencontainers/tob#2). Based on 2, I expect
@RobDolinMS can fill in some details on the certification program.

Once you have an OCI-run certification program, they just need a way
to publish their results. I'm sure there's lots of prior art in this
space (and I'm not familiar with it), but Open Badges 3 are one way
I've heard for a certification authority to provide a verifiable
certificate via a pretty, embeddable graphic. And just having a list
of certified runtimes (for each certified runtime/specification
version combination?) on opencontainers.org somewhere would be a
simple approach if embeddable graphics aren't a requirement.

[liangchenye]

@wking, thanks, I'm reading openbadges.org now.

[caniszczyk]

As @wking pointed out, the OCI Certification program falls under the purview of the OCI Trademark Board (https://www.opencontainers.org/about/governance)

i. creating the OCI trademarks associated with OCI Projects (including the OCI Specification Project), the Open Container Format (OCF) or OCI certified solutions.
ii. creating a certification program establishing the requirements for achieving the status of an “OCI Certified Solution” and defining the terms for using any OCI trademark(s) for an OCI Certified Solution;

Initial discussions are around having three levels of certification:

• OCI Runtime Ready (runtime-spec only)
• OCI Image Ready (image-spec only)
• OCI Certified (both specs)

It's still up in the air in terms of how the certification program will be fully defined and administered. It's something we hope to tackle very soon after v1.0

However, I encourage people to improve the tooling as I'm pretty sure we will be using the tooling out of the ocitools and image-spec repos (assuming ocitools isn't merged into runtime-spec)

[wking]

On Mon, Jun 06, 2016 at 08:08:16AM -0700, Chris Aniszczyk wrote:

Initial discussions are around having three levels of certification:

• OCI Runtime Ready (runtime-spec only)
• OCI Image Ready (image-spec only)
• OCI Certified (both specs)

The per-spec certs should probably be broken down further into “is a
certified implementation” (e.g. runC v1.0.0) and “is a valid consumer”
(e.g. example.com/redis v3.2).

However, I encourage people to improve the tooling as I'm pretty
sure we will be using the tooling out of the ocitools…

+1.

[caniszczyk]

@wking can you expand a bit on, not sure what you mean by "valid consumer"

The per-spec certs should probably be broken down further into “is a
certified implementation” (e.g. runC v1.0.0) and “is a valid consumer”
(e.g. example.com/redis v3.2).

[wking]

On Mon, Jun 06, 2016 at 09:11:56AM -0700, Chris Aniszczyk wrote:

@wking can you expand a bit on, not sure what you mean by "valid consumer"

‘ocitools validate’ 1 tests the stuff supplied by these people 2
for compliance. ‘test_runtime.sh’ 3 tests the stuff supplied by
these people 4 for compliance. Since the testing is different, I
think we want to be using different names for the cerificates.

[iamanush]

@RobDolinMS 8. should be sudo apt-get install go-md2man.