OCI Reveals Governance Structure Amid Debate Over Focus
That symbolic handshake last summer at DockerCon between Docker CTO Solomon Hykes and CoreOS CEO Alex Polvi didn’t necessarily mean there’s peace in the container format front.
The Open Container Initiative (OCI), now a Linux Foundation Collaborative Project, aimed to build a vendor-neutral, portable and open specification and runtime for container-based systems, announced its governing structure Tuesday.
At the same time, Polvi, in a blog post, charged that the project is too narrowly focused.
“While we are happy the industry has come together to support the OCI runtime, CoreOS believes that the most critical aspect of container standards is the distributable container image: the part that gives end-user portability. This component is not currently addressed by OCI, which is why it is important to continue our work with [its specification] appc,” he writes.
Project Governance
OCI announced Tuesday it now has 38 member companies: Amazon Web Services, Apcera, Apprenda, AT&T, ClusterHQ, Cisco, CoreOS, Datera, Dell, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, Hewlett Packard Enterprise, Huawei, IBM, Infoblox, Intel, Joyent, Kismatic, Kyup, Mesosphere, Microsoft, Midokura, Nutanix, Oracle, Pivotal, Polyverse, Portworx, Rancher Labs, Red Hat, Resin.io, Scalock, Sysdig, SUSE, Twistlock, Twitter, Verizon, VMware and Weaveworks.
It announced the project’s technical roadmap, and a technical developer community (TDC) that includes independent maintainers as well as maintainers from founding members including Docker, CoreOS, Google and Huawei.
A technical oversight board (TOB) will be appointed by the members of the OCI and the TDC to ensure cross-project consistencies and workflows and to serve as an appeals board when disputes arise. The governance model also includes a trademark board to oversee the development and use of the OCI’s trademarks and certifications.
The group’s focus will be on creating a standard that’s composable, portable, secure, decentralized, open, minimalist and backward compatible, according to the announcement.
The maintainers, from the original libcontainer project — Michael Crosby, Rohit Jnagal, Victor Marmol, Mrunal Patel , Alexandr Morozov, Daniel Minh and Tianon Gravi as well as appc maintainers CoreOS CTO Brandon Philips and Vincent Batts — wasted no time getting started and since June created two releases of the specification and six releases of the runc implementation, Docker’s Patrick Chanezon told The New Stack.
And Cloud Foundry has implemented runc as part of its Garden project.
Running with runc
Docker originally described runc as “basically everything you need to run containers on a low-level system, and nothing else” with the purpose of making the code used by containers to access system services, accessible to outside communication.
It scored a coup within the project by making it the basis of the OCI project, while CoreOS was advocating for and trying to build a coalition around its appc specification.
“It was very clear from the get-go that we wanted this project to have a strong reference implementation. So the project as part of its charter had runc or the libcontainer project as the reference implementation,” Chanezon said. “There was some discussion about whether it should be runc or something brand new, but since libcontainer was already using Docker to run all the containers running today, [it was clear that] runc would be the best thing for that.”
Divergent Paths
Hykes and Polvi did not agree to unify their formats earlier this year. And the two companies continue to take divergent paths toward container security – that being the issue behind Polvi’s argument last December in which he called Docker’s security model “fundamentally flawed.”
CoreOS recently announced software, called Clair, that compares the contents of a container against a number of Linux distribution-specific vulnerability databases. And Docker announced security enhancements including hardware signing of container images, content auditing through image scanning and vulnerability detection, and expanded access control policies with user namespaces.
“While today’s announcement helps further clarify the scope of OCI, we believe there is more work to do for the container specification to be complete and achieve true interoperability,” Polvi wrote in his blog post.
“The idea behind OCI was to take the widely deployed runtime and image format implementation from Docker and build an open standard in the spirit of appc. We jumped at this prospect, as having one shared standard is a unique opportunity to foster wide proliferation and adoption of containers and a healthy ecosystem of competing implementations.
“While initially it appeared there was some overlap between OCI and appc, the OCI has solely focused on the runtime, which is more narrowly focused than we anticipated for the project. Our efforts to bring in container image and image distribution of appc have not been incorporated, but we still believe these are important parts of a container standard.”
He said CoreOS will take the open source projects it has built, “projects essential to furthering the adoption of this style of infrastructure” to the Cloud Native Computing Foundation (CNCF), another Linux Foundation collaborative project. Those projects include:
- etcd, a distributed, reliable key-value store for the most critical data of distributed systems.
- flannel, a virtual network fabric for containers.
- appc components that are not covered by OCI, like the image format and discovery.
As Jason Mendenhall, executive vice president, Cloud at Switch and a member of CNCF, described the differences between the two projects:
“The OCI is very focused on just the container. What are the standards a container would run on?” he said. “You can download some software and your laptop can be an environment where you develop in a container-based system. But when you start talking about managing large application frameworks, having your integration team put it on a cloud or building your own cloud, no matter how you’re doing it, that’s where things are really starting to break – this idea of going up stack,” he said.
“Because we can do so much with it, complexity is going to be problematic. With the Cloud Native Computing Foundation, as things move into more large-scale production environments, we’re trying to establish a platform by which reference architectures can cohabitate and be certified — these are the series of tools that make this environment work.”
And Polvi added: “Of course, there is always risk that by putting software into a foundation, it actually has the opposite effect, slowing down the project. We believe that the approach CNCF is taking is spot on, but as we move forward we will be careful to do what is best for increasing the adoption of etcd and thus cloud-native infrastructure.”
CoreOS and Docker are sponsors of The New Stack.
Feature Image: “Lonely Pathway” by Tilemahos Efthimiadis, licensed under CC BY-SA 2.0.
