[Container-tools] docker container based installers for Atomic / OpenShift V3 / GKE et al (was Re: Container App Spec and Tooling

[James Strachan]

> On 30 Apr 2015, at 15:14, Christoph Görn <goern at redhat.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi... inlined //G
> 
> On 04/30/2015 03:32 PM, James Strachan wrote:
>>> On 30 Apr 2015, at 12:41, Christoph Görn <goern at redhat.com 
>>> <mailto:goern at redhat.com>> wrote:
>>> 
>>> On 04/30/2015 11:43 AM, James Strachan wrote:
>>>> I think having a docker container based installer of
>>>> kubernetes apps or OpenShift templates is going to be very
>>>> useful.
>>> 
>>> The Atomicapp will not only create openshift templates but also
>>> route, service and all other kind of objects... So what you are
>>> referring to as an "OpenShift template" is what an Atomicapp
>>> would carry as "a openshift provider specific artifact”.
>> 
>> In our case; we’re curating our own OpenShift templates as are
>> others (Cloud enablement folks, Management.Next folks); we just
>> need a way to package them up and compose them together
> 
> Ja, doable, as you can put anything in your layer of the Atomicapp's
> openshift provider artifacts directory.

Coolio


>>>> Its pretty trivial to take an OS template and expand it purely 
>>>> client side in the installer then turn it into normal
>>>> kubernetes stuff; so am even tempted to just say everything’s
>>>> an OpenShift Template (with some things not having any
>>>> parameters) - then if not using OpenShift we’d expand the
>>>> templates on the fly first before applying them?
>>> 
>>> Ja, sound like the way we are going to implement the openshift 
>>> provider within the Atomicapp.
>> 
>> TBH I’m currently leaning towards using OpenShift Templates
>> everywhere; so there’s only 1 provider;
> 
> That's ok. If you want to support only OpenShift than do so.

I think you missed my point. An OpenShift template can be used on any Kubernetes environment at all - including Atomic and GKE. Since an OpenShift template is a client side preprocessor; it outputs vanilla Kubernetes JSON


> There are
> use cases where both an kubernets and a docker provider make sense too.

Similarly; its pretty easy to translate a kubernetes JSON to run it on a local machine with just docker too.

Not a biggie though.


> 
>> e.g. here’s one of them, our HTML5 console… 
>> http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/console
> /2.0.47/console-2.0.47-kubernetes.json
>> 
>> if we can get a reusable docker base image I can get our build
>> process to try create a docker image with all the kubernetes json /
>> OpenShift templates inside and we can experiment more…
> 
> Ja, lets close https://github.com/vpavlin/atomicapp-run/issues/23 and
> than have a look at the console.

Cool