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

Re: OpenShift v3 PEP



----- Original Message -----
> From: "Clayton Coleman" <ccoleman redhat com>
> To: "Openshift Dev" <dev lists openshift redhat com>, users lists openshift redhat com
> Sent: Thursday, July 24, 2014 8:44:06 PM
> Subject: 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 i!
>  n 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)

This seems like a slightly mismatched mapping since the image repository will contain (I think?) both fully runnable images (equivalent to a binary deploy..no build step) and builder images (need to be combined with source to be run).  

Cartridges today are much more the latter than the former (aside from the template code, they have no runnable source associated).

There may not be an appropriate term/mapping in v3, but I just wanted to point out the expansion in meaning associated with a v3 image repository, as compared with a v2 cartridge.


On a related note, I'm not entirely clear (after reading the PEP) on the difference between an image stream and an image repository.  Are they being used interchangeably?  Does an image stream simply wrapper additional metadata around an image repository?



> 
>  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
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


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