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.