eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Linux Foundation today announced that the Open Container Initiative (OCI) has hit a major milestone in its evolution, approving a formal governance structure.
The OCI was first announced in June as a way to bring together rival container efforts to create a standard that enables interoperability. Members of the OCI include Amazon Web Services, Apcera, Apprenda, AT&T, ClusterHQ, Cisco, CoreOS, Datera, Dell, Docker, EMC, Fujitsu, Goldman Sachs, Google, Hewlett Packard Enterprise, Huawei, IBM, Infoblox, Intel, Joyent, Kismatic, Kyup, Mesosphere, Microsoft, Midokura, Nutanix, Odin, Oracle, Pivotal, Polyverse, Portworx, Rancher Labs, Red Hat, Resin.io, Scalock, Sysdig, SUSE, Twistlock, Twitter, Univa, Verizon Wireless, VMware and Weaveworks.
The new governance model for the OCI includes a Technical Developer Community (TDC)—the group that is leading the technical development of the container runtime. According to the newly approved charter for the OCI, “the OCI TDC shall be open to any developer, end user or subject matter expert that chooses to participate in the activities of OCI, regardless of whether the participant is employed by an OCI Member company so long as his or her contributions and conduct comply with this Charter.”
On top of the TDC is now a Technical Oversight Board (TOB), which is made up of nine individuals. The goal of the TOB is to manage conflicts and help settle disputes that might arise in the TDC.
“The goal of the TOB is to be an appeals board,” Patrick Chanezon, member of the technical staff at Docker Inc., told eWEEK. “If there is a disagreement about technical features, developers can appeal to the board.”
The final piece of the new OCI governance model is a Trademark Board that will have oversight over OCI certification and trademark efforts. The goal with certification is to have a process in place to properly validate what is an OCI-compliant container runtime.
The OCI has several efforts, with a primary initiative being the RunC container runtime. RunC was originally derived from the nsinit component of the Docker libcontainer technology.
“OCI is covering the runtime side of containers, which is a great thing,” Alex Polvi, CEO of CoreOS, told eWEEK. “This means rkt and Docker will be able to share exec drivers so our engineering teams only need to invest in building a limited set of runtimes.”
CoreOS split from the mainline Docker community in December of 2014, launching its rkt (Rocket) container technology as an alternative to Docker.
The OCI is also working on an Open Container Specification that is publicly viewable on Github. Chanezon explained that the filesystem bundle component of the specification aims to define how files are laid out on the filesystem in order to run an OCI-compliant container.
“The filesystem bundle does not talk about the distribution of application images,” Chanezon said. “There have been two different formats that have been used historically for Docker, the Docker image format version 1 and version 2.”
CoreOS has been advocating a standard application image format approach called appc. The basic idea behind the OCI approach is that there is a component that gets the application image from a container application repository and then lays it out on disk in a standardized way, and from there the user can run the application with any OCI-compliant container runtime, Chanezon said.
“The way people will use RunC is they will pull an image from Docker Hub or from CoreOS’ quay.io or some other repository and then RunC will create a container based on that image,” he said.
From CoreOS’ perspective, there still is a need for a standard image format for container applications.
“We believe end users, operations teams and developers should to be able to create their container image once, sign it and run it in a variety of runtimes,” Polvi said. “A standard container image, as with ACI [App Container Image], makes it possible to run your container anywhere, as well as eliminate vendor lock-in and encourage a variety of implementations.”
Polvi explained that the OCI format is an internal implementation format of the container runtime itself, not an image that an end user creates. In his view, they are different things all together—not that one is lacking something from the other.
“We are supportive of OCI and having come together as an industry to support OCI,” Polvi said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.