[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

OpenShift v3 PEP



A draft version of the OpenShift v3 (that's system level version, not release version) PEP is now available at

 https://github.com/openshift/openshift-pep/blob/master/openshift-pep-013-openshift-3.md

In v3 there are a few major transitions being proposed.  

First, Docker.  No surprises there - we're committed to evolving our OpenShift container story with gears and cartridges to take advantage of images and the community that has emerged around Linux containers, and to enable execution of containers at the largest scales while giving operators control over how software updates flow through an organization.  At the same time, many developers on Windows or Mac won't know or care about the underlying container runtime, and only the improvements we can offer them for building and customizing their cartridges and application source code will matter.  With Docker, we want any image anyone creates to be usable as a component of your application.

Second, the introduction of Kubernetes [1] as a core component of the OpenShift system.  Kubernetes would be the foundational code for what we call the Broker - major elements of the OpenShift API, plugins and integration with authentication sources, and the scheduling and orchestration code that puts gears onto hosts.  We believe strongly in the model and principles that Google launched the project with, and we think that there is a lot of value to bring to developers and operators.  A key component of that change is allowing increasing sophistication of deployment and topology and exposing even more ways of putting applications together.  We also wish to bring in the expertise of the big data communities and their job scheduling experience through the Kubernetes project - letting administrators coschedule batch jobs and containers together on infrastructure.  And we want to make the underlying infrastructure OpenShift runs on be available for small and medium deployments in a painless, easy to setup way, with close integration with systemd and RHEL7.

Third, we want to focus on enabling more complex application topologies than the 2.x model currently allows.  That means relaxing restrictions originally put in place to make things easy for new users.  With 3.x, you'll be able to tie tiers of software together organically and manage the relationships between those containers.  Some easy goals: run databases as standalone services, wire them up to multiple web tiers, and assemble multiple web applications into modern service oriented architectures.  A key goal is enabling clustered software like MongoDB replica sets, MySQL master-slave clusters, Cassandra, and others, and being able to create templates that let you deploy those configurations repeatedly.  At the same time, we want to make it easier to depend on other *aaS solutions like OpenStack and our partners in the OpenShift Marketplace, so wiring your software up to external components and depending on them will be trivial.

Fourth, integrating the core OpenShift technology with the xPaaS and Fabric communities will enable new opportunities for those building on top of Java middleware.  We're very excited about ensuring that the Docker and topology capabilities we're planning match well with the powerful compositional tools for messaging, microservices, and event pipelining that Fabric will bring.

Finally, compatibility between 2.x (oo4) and 3.x (oo-next) will be critically important.  While the introduction of Docker represents a big shift at the host level, we plan on ensuring that existing OpenShift applications can move into Docker containers with minimal effort.  In addition, transitioning across deployments will be even easier given the new routing layer.

The PEP has a lot of new terminology; as OpenShift has evolved, we've refined use cases underneath some of our existing terms and found we've drifted rather far from where we started.  Many of the new names in the PEP are simply restatements of our old concepts, and not all of them may survive the subsequent discussions and implementations.  Here's a quick mapping to the PEP:

 Cartridge -> Image Repository
  (a cartridge is a way of providing updated binaries to end users without disruption, and an image repo should be similar)

 Domain -> Project
  (domains today map very closely to projects)

 Application/Gear Group -> Service
  (application has a lot of connotations, a service is a bit more constrained)

 Gear -> Container
  (a gear is already a container)


This is a big chunk of PEP, but it represents a lot of discussions and suggestions from many people across the OpenShift community.  Please leave feedback or ask questions as you can - help us sketch out the future of OpenShift!

[1] https://github.com/GoogleCloudPlatform/kubernetes

Clayton Coleman | Lead Engineer, Red Hat OpenShift


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]