The Open Container Project is born

Posted Jun 25, 2015 14:48 UTC (Thu) by jhhaller (guest, #56103)
Parent article: The Open Container Project is born

To take the railroad analogy further, while this may set the standard for the width of the rails, it doesn't specify the type of coupler used between cars, or the height that the floor of a boxcar may sit, leading to a need for different height loading platforms.

There is some amount of orchestration-awareness a container has to have to work with an orchestration system. How the container configuration is passed into the container needs to be standardized, at least to the point the container knows what kind of orchestration is being used. Otherwise, we are still left with building different containers for different orchestration systems. Should it access etcd, Consul, a mounted filesystem, or environment variables? I hope that at least the first-level of this configuration is standardized.

The Open Container Project is born

Posted Jun 25, 2015 20:55 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

I get nervous about trying to do this sort of standardization as it seems to lock us into the way that we are doing things today, making it harder for people with radically different approaches to do something new.

Standardizing the definition of a container (resources it can use, storage it can access, etc) is a very good thing to do.

Standardizing what must be inside the container, is less than obviously a win.

As for your example:

>Should it access etcd, Consul, a mounted filesystem, or environment variables?

doesn't that depend on the software that's inside the container and what it's configured to do? You aren't saying that a given container blob should be able to support multiple different ways of getting it's config are you?

The Open Container Project is born

Posted Jun 25, 2015 22:36 UTC (Thu) by jhhaller (guest, #56103) [Link] (2 responses)

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.