community (hosted by the Linux Foundation) for building a vendor-neutral, portable and open specification/runtime that delivers on the promise of containers as a source of application portability backed by a certification program.
Board shall be composed of one representative appointed by each OCI Member; responsible for trademarks, certification, budget • Technical Development Community (TDC) – open to any individual or any open source contributor • Technical Oversight Board (TOB) – responsible for managing conflicts, violations of procedures or guidelines and any cross-project or high-level issues that cannot be resolved in the TDC for OCI Projects. The TOB shall also be responsible for adding, removing or re-organizing OCI Projects.
MUST release at least three release candidates spaced a minimum of one week apart. This means a major release like a v1. 0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself. Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD add restart the three-candidate count when a breaking change is introduced. For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1. 0.0.”
of a container – https://github.com/opencontainers/runtime-spec • image-spec – a software shipping container image format spec with security and naming as components – https://github.com/opencontainers/image-spec What is the current state of the OCI specifications?
OCI Trademark Board working to propose a set of criteria for implementations to meet if they want to use OCI trademarks (Open Container Initiative, OCI Certified, etc.) • Implementers whose implementations meet the bar of OCI certification can use OCI trademarks in marketing their solution • Users/customers can look for OCI Certified implementations to know that they are getting interoperable solutions • Implementers who want to build solutions can leverage/target OCI interoperability surfaces rather than having to build for multiple, inconsistent interoperability surfaces What does the certification working group do and what value can a certification program bring?
container technology? Questions being considered by the OCI Cert WG: • Implementations: ◦ Runtime spec ◦ Image format spec ◦ Both • Levels of compliance: ◦ MUST/REQUIRED == Compliant ◦ MUST/REQUIRED + SHOULD/RECOMMENDED == Unconditionally compliant • Testing: ◦ Automation vs. manual: Can we fully automate? ◦ Lab vs. peer vs. self: What optimizes cost and compliance
community and projects! ◦ Weekly technical meetings open to all ▪ https://github.com/opencontainers/specs#weekly-call ◦ IRC: #opencontainers at irc.freenode.net ◦ GitHub ▪ https://github.com/opencontainers/runtime-spec ▪ https://github.com/opencontainers/image-spec ▪ https://github.com/opencontainers/ocitools ◦ Mailing list: firstname.lastname@example.org ◦ Roadmap (milestones) ▪ https://github.com/opencontainers/runtime-spec/milestones ▪ https://github.com/opencontainers/image-spec/milestones • Consider joining and what role you would like to play in the initiative ◦ https://opencontainers.org/join