Packaging Che to run on OpenShift

[TylerJewell]

This is a specification for all of the work to be done to productize Eclipse Che to run and operate on Kubernetes-based OpenShift. This is a particularly challenging task as we have to decouple the internal Docker management operations of Che into an abstraction layer that can delegate those functions into an OpenShift provider, which itself must map those commands to OpenShift APIs. Additionally, OpenShift was originally designed for applications that are fairly well self-contained, but Che is an application which itself is also responsible for creating and managing containers, and needs to have certain control hooks into the underlying orchestration system.

@l0rd - has started on a prototype that has programmatic controls over how to create and destroy workspaces using only OpenShift APIs. This is the work product of what is needed to productize all of this work.

• Che core needs to implement Service Provider Interface which abstracts core Docker functions to delegate to a provider. We will have providers for Docker & OpenShift initially. A swarm provider is likley as Codenvy runs itself on a Swarm implementation. Environment Provider and Agent SPI #2355

• Enabling Che workspaces to launch, run, and stop within a OpenShift pod.
  • Use OpenShift API instead of Docker API to start and stop Che workspaces CHE-26: Initial OpenShift integration #3798
  • Switch between OpenShift API and Docker API using a property in che.properties CHE-26: Initial OpenShift integration #3798
  • Add the needed OpenShift connector dependencies CHE-55: Adding io.fabric8 dependencies che-dependencies#23
  • Extend Che CLI to generate an OpenShift Template and deploy it

• (*) Remove --privileged container constraint for running Che workspaces in OpenShift. Privileged flag is required for any situation where we are not using the OpenShift APIs, we are exposing services on ephemeral ports, we are using host path volumes.
  • (*) Replace all the remaining call to the Docker API with OS API OpenShift API implementation #3031
  • (*) Use Persistent Volumes Claims
  • (*) Workspaces services should be exposed on port 80 or 443 only

• Documentation and marketing updates:
  • Deployment of Che on OpenShift https://github.com/codenvy/che-docs/issues/76
  • Custom assembly and template for running Che with OpenShift plugin (also deploying into OS)
  • Marketing sub-site at www.eclipse.org/che to treat the OS custom assembly as a specialty product

(*) work has been merged in openshift-connector branch only.

[vazexqi]

Apologies if this is not the right venue for asking this. I have checked the che-dev mailing list on Eclipse and more activity seems to be going on on GitHub issues than there.

I see that there is a branch (https://github.com/eclipse/che/compare/openshift-connector) that seems very specific to getting Che to run on OpenShift stack. But I was watching the CheConf presentation by @l0rd on Deploying Che on OpenShift and there was some mention of a more general Service Provider Interface (SPI). Is the work for SPI planned for Che 5.x?

[l0rd]

Hello @vazexqi we want to merge openshift-connector branch to master really soon. That's the first step towards a more generic SPI. Are you interested in a particular connector besides Docker and OpenShift?

[TylerJewell]

I think @vazexqi - is referring to this epic - #2355. Our thinking on timing is that we are working really closely with Red Hat to get Che to work properly on OpenShift first. As part of this, we are breaking a numbef of interfaces between Che and the Docker daemon. Once we have a verified Che that works with a normal daemon and with OpenShift, we can then create a general purpose SPI that allows for adapting Che functions to any type of container provider.

[vazexqi]

@l0rd @TylerJewell - Thanks for the update. I'll continue to monitor to see when something more generic comes about. I don't have concrete plans on a particular connector, but I am interested in seeing if/how Che can be hosted on a PaaS instead of an IaaS platform. OpenShift seems to fall more into the PaaS domain so this is of interest to me.

[TylerJewell]

The SPI that we are discussing here is specific to the container infrastructure layer ... which pre-supposes that you have configured Che to use the "Docker Machine", which is also the default. "Machines" are a different abstraction (with an existing well defined interface), which is an abstraction for "type of runtime". so a machine could be a container, a VM, a MacMini - as examples. We have done two types of machine implementations - Docker & SSH. The SSH machines assume that there is a remote runtime that can be connected to over an IP address + authentication. But you could envision this interface being used for a variety of different implementation types - where machines have a specialized activation profile, a definition of a recipe, and the so forth. We could, for example, have a Vagrant machine type.

[TylerJewell]

@l0rd - I have updated the main body of the epic. If you think it would be helpful to rewrite that body to remove duplication and to also refresh it for the current scope, we should do that, so that we are working from a single list of activities.

[l0rd]

Tyler I've edited this epic description. In particular I've:

• Removed item "Provide configuration to allow Che server and workspaces to run on different nodes" (that's a duplicate of previous items)
• I moved "Cli extension" item to section "launch, run and stop" since it's not related to the --privilege flag.

[TylerJewell]

Thanks - I think it looks good.

[pittar]

This is fantastic. We're on the verge of adopting OpenShift at work and we've also been trying to figure out how we could host our own internal Che server. This could be a really great solution!

[slemeur]

Closing as it will be fixed with:

• OpenShift infrastructure implementation of SPI #5098
• Che deployment on OpenShift should be as simple as on Docker  #6097