The Open Container Project is born

Posted Jun 25, 2015 22:36 UTC (Thu) by jhhaller (guest, #56103)
In reply to: The Open Container Project is born by dlang
Parent article: The Open Container Project is born

Given that OCP is designed to unify containers, it would be nice to build containers which work in multiple orchestration systems. I work for a company which supplies network providers, and unless a unifying orchestration standard emerges, different customers will pick different orchestration systems, and then we would have to work with all of the ones our customers have chosen. I'd prefer not to have to build 5 different containers where 95% of the code was common. This may not be the most common use case, but it is one.

The Open Container Project is born

Posted Jun 25, 2015 23:36 UTC (Thu) by dlang (guest, #313) [Link]

I think that would be like unifying distros. There are good reasons that different people choose to build containers differently and use different orchestration systems.

I wouldn't want to try and maintain a container definition that attempted to support every possible orchestration system out there, and I don't think that we are anywhere close to the point where we can standardize how orchestration systems work.

you say you don't want to build 5 different containers where 95% of the code is common, but I think if you tried to cover all possible orchestration systems, it would be more like 20 containers. And I don't want the container to be 50% unused code to support orchestration systems that I'm not running. That way lies bugs, backdoors, and a security nightmare.

The Open Container Project is born

Posted Jun 26, 2015 12:44 UTC (Fri) by massimiliano (subscriber, #3048) [Link]

IMHO a container is just a set of namespaces (for file systems, network interfaces, processes...) that is meant to isolate a "component" (application, service, microservice... whatever) from the rest of the "system" (whatever "system" might mean).

Standardizing ways of building the contents of a container is really a good thing, we should be ready for that.

However it seems too early to also standardize the way in which containers are composed. For instance, I see different ways to set up complex virtual networks of containers (flannel, kubernetes, mesos...), and I don't think we should attempt to "mandate" the use of one instead of another. The "community" is still understanding how these compositions are supposed to work!

In the same way, a key value store to keep configuration could be etcd, zookeeper, consul, or anything else, but each "application" should pick its own choices, and also each "container composition or orchestration system".

Of course, my 2c.