The Open Container Initiative (OCI) was formed in June 2015. Their main goal was to establish common standards for software containers. It was originally named the Open Container Project and later became a Linux Foundation project. Founding members included CoreOS, Amazon Web Services, Apcera, Cisco, EMC, Fujitsu, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat, and VMware Docker.
Initially, OCI began creating run-time standard specs, but later the group agreed to deal with container image format specs. The project has been around for more than year now, and, on July 13, 2016, IBM hosted an online panel titled “Open Container Initiative at 12 Months” to provide an overview of what the project has achieved so far.
Five members of the OCI project participated in the panel, including Michael Dolan (The Linux Foundation); Jeff Borek (OCI Cert WG Vice-Chair); Michael Crosby (OCI Runtime spec lead maintainer); Rob Dolin (OCI TB certifianton WG co-chair), and Mrunal Patel (OCI Runtime spec maintainer).
The panel was moderated by Dolan who works at Microsoft as Senior Program Manager and Technical Diplomat, and the discussion was focused on providing people with an overview of OCI’s progress.
Dolan started with an overview of why the OCI was created in the first place. The primary objective was to address the emerging space around containers, in particular the rise of Docker containers and other container platforms. Within that, an open source community has been developed and curated under The Linux Foundation. The OCI is working on vendor neutral, portable, and open industry standards around container formats and runtime.
He said that their goal is to deliver the promise of containers as the source of application portability. It’s an extremely important issue. As containers proliferate, many companies are deploying thousands of containers, and there is a pressing need for runtime standard spec. OCI is also curating a certification program to ensure that those containers meet the standards that have been developed in OCI.
As of May 2016, 46 organizations have signed up as members of OCI. These organizations are supporting the community and enabling the great collaboration that’s under way.
How the project is structured
The OCI project’s governance has remained fairly lightweight and has a streamlined process in terms of what is to be done and by whom. To deal with business matters like trademarks, budgets and certifications they have set up a Trademark Board (TB), in which any member of the OCI can participate.
The TB is maintained completely independently of any technical work going on. All of the technical work, including collaboration of both the open source code base and specification for containers is done in the Technical Development Community (TDC).
Unlike the Trademark Board, the TDC is not restricted to members. Anyone who is interested can participate, just like any other open source project. Dolan said that in addition to technical work, a lot of non-coding work is needed, and he invited people to participate in things like documentation and testing.
The third entity is the Technical Oversight Board (TOB), which was elected to deal with more challenging issues. This includes managing conflicts between projects, violations of procedures and guidelines, and any cross-project issues that need high-level assistance. Dolan said that the TOB is really meant as a last resort for issues that can’t be addressed or resolved within the Technical Developer Community for the projects.
The TOB is also responsible for accepting, removing, or archiving any OCI project that has been accepted. Currently, two projects are being worked on, and in the future the TOB will be responsible for adding new projects or sunsetting projects if they are no longer being worked on.
Many processes are still TBD
Crosby talked about the release process and current state of specs. Crosby said that the release process is currently a work-in-progress. They have now a basic outline of how they want the releases to work with the specification and any code that will be released. He said that there are couple of pull requests submitted that address how OCI is changing the release process.
OCI has been around for a bit longer than a year now, and the project has reached some milestones to where they are now thinking about releasing the 1.0 spec, how to handle changes, and supporting backward and forward compatibility in the future.
Overall, it’s still work in progress, and Crosby invited people to get involved as there is an open conversation going on in the GitHub repo.
Status of container specs
Crosby then talked about the two existing projects in OCI: Runtime specs and Container Image format specs. OCI started off with the Runtime spec as the first project from day one. It included the standard I/O for containers so that the input and output for the container was standardized.
The group is now are working on version 1.0 of the Runtime spec; RC 1 was released two weeks ago. They are gathering feedback and adjusting any open issues on that RC. They have been iterating on the RC to make it stable. He said that everything is looking good on the Runtime side.
Next, he talked about the Container Image format spec that started off in March this year. OCI imported Docker v2 image, and it was worked upon by various maintainers and people from the TDC. The Container Image Format spec deals with how containers are packaged and moved around. There is a lot of work going on, and the 0.3.0 release is expected soon. He pointed out that both specs will interoperate with each other and provide end-to-end use case for containers.
He said that they are trying to keep a one to two months release cycle for the Runtime spec and the Image spec will follow the same cycle. All of these releases are tagged and pushed on GitHub repos where people can check them out and contribute.
When Dolin asked about the status of the source code, Crosby talked about runc, that is the reference implementation of OCI Runtime spec. He said that runc implements the specs to the fullest. It allows you to spin containers, interact with them, and manage their lifecycle. The code is already available in the GitHub repository. Crosby emphasised that it’s a very solid container Runtime where you can start building high-level systems on. Patel then talked about the OCI tools that allow developers to validate their runtime and make sure it’s compliant with OCI.
Borek described work being done on certification side. He said that while a lot of people are collaborating and supporting the evolution of the technology, they are trying to do it in a balanced way because they don’t want to expand the scope of the OCI too much. He said that at OCI they want to follow the shipping/container metaphor and come up with an open standard way to specify Runtime and Image Format while allowing a lot of creativity and innovation in the broader ecosystem to bring the full potential of this technology forward.
He said that they are discussing whether to focus strictly on a list of must level of compliance or consider more fine-grained must and should types of processes for evaluating container compliance. OCI is trying to strike the right balance between simplicity and providing enough granular focus to ensure that the proper level of base technology is perpetuated as part of this working group.
Dolin concluded the webcast by inviting people to join and get involved with the OCI project. They organize weekly technical meetings that are open to everyone. You can get in touch through GitHub, mailing list, and IRC chat on IRC freenode.
