easy way to import apps into the OpenShift template library?

[jstrachan]

we create lots of apps for running on OpenShift in each fabric8 release. Here's the source for them all if you want a look.

then each release ships with a zip of them all. e.g. the 2.0.39 release:
http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.0.39/

see the app.zip file which is a zip of all the apps; each app zip is a kube json + icon + readme etc.

in the fabric8 console you can drag and drop zip files into the console library; or drag and drop from the console to the desktop for a simple kind of "Apps Library" a little like your iTunes library for mobile apps.

It would be pretty handy for folks to be able to run all the fabric8 apps from inside the OpenShift console too; using the 'create template' stuff; we'd just need a way to be able to import the apps (templates) into OpenShift.

Is there an easy way to do such a thing; or can we add it?

We're encouraging java folks using Maven to reuse the same maven tooling to generate their own apps / app zips as well; so this tool would be reusable by customers & users too I should think.

[smarterclayton]

I don't see why not. One way (maybe not the best way, but a possible way) is to do the following transformation:

1. The name of the directory becomes a template name
2. The body of the template is kubernetes.json (the "objects" field can be the config "items" field)
3. Store the readme as the description (we should supported limited markdown in descriptions, or have a way to indicate the description is markdown)
4. Store the app icon as a base64 encoded annotation, maybe as a data URI, named "openshift.io/icon-image" or similar on the template - the console should be able to then use it as a base64 url. Data URI is best because we can use it directly.
5. Store other files as annotations if needed.

Templates don't need to have parameters - seems like a good way to bundle them. If you change the build output to also generate the template.json (or generate a directory of json) someone could then osc create -f it all at once.

The UI changes after that should be easy.

[jstrachan]

thanks @smarterclayton that sounds good to me. I'm a little nervous of the size of pod / RC json having icons in there by value rather than reference; I'd prefer a real URI path to icons but I guess thats a more long term optimisation. e.g. to avoid loading a 30k icon for every pod when you've lots of pods with the same icon.

I'm gonna take a stab porting the fabric8 maven plugin that generates the kubernetes.json / app zips to generate an OpenShift template for each app.

I wonder if we had, say, 20 templates is there gonna be an easy way to import them all into an OpenShift installation easily? I can certainly make a zip of them so they are easy to download/unpack at least; I guess they can be placed somewhere on the file system so the openshift master & console can find them?

[smarterclayton]

On Apr 8, 2015, at 1:25 PM, James Strachan notifications@github.com wrote:

thanks @smarterclayton that sounds good to me. I'm a little nervous of the size of pod / RC json having icons in there by value rather than reference; I'd prefer a real URI path to icons but I guess thats a more long term optimisation. e.g. to avoid loading a 30k icon for every pod when you've lots of pods with the same icon.

Oh, I wasn't expecting to put that into the pod. We should be able to tie image repositories to icons maybe.
I'm gonna take a stab porting the fabric8 maven plugin that generates the kubernetes.json / app zips to generate an OpenShift template for each app.

I wonder if we had, say, 20 templates is there gonna be an easy way to import them all into an OpenShift installation easily? I can certainly make a zip of them so they are easy to download/unpack at least; I guess they can be placed somewhere on the file system so the openshift master & console can find them?

Yeah, it should be a single command "osc create -f " which will bulk import all the files.
—
Reply to this email directly or view it on GitHub.

[jstrachan]

@smarterclayton oh you mean just annotate the template; but not annotate the pod / RC right? If so sure thats good ;)

Am just wondering how we'd find the icon URL for a pod/RC/service; do kubernetes resources get annotated with the template ID?

[smarterclayton]

We could annotate the service actually - that one seems like the natural fit. So the template itself could put the annotation on its services.

On Apr 8, 2015, at 1:35 PM, James Strachan notifications@github.com wrote:

@smarterclayton oh you mean just annotate the template; but not annotate the pod / RC right? If so sure thats good ;)

Am just wondering how we'd find the icon URL for a pod/RC/service; do kubernetes resources get annotated with the template ID?

—
Reply to this email directly or view it on GitHub.

[jwforres]

CC @liggitt

[liggitt]

one thing to be aware of is the size limit on annotations... 64k, I think

[smarterclayton]

Total, across all values

On May 8, 2015, at 9:44 PM, Jordan Liggitt notifications@github.com wrote:

one thing to be aware of is the size limit on annotations... 64k, I think

—
Reply to this email directly or view it on GitHub.

[danmcp]

Any remaining issues here?

[jstrachan]

I'm cool with annotating just the templates. What worries me is the 64k limit on annotations; that rules out lots of possible icons already; many PNG icons are over 30k before they get base64 encoded (and some are over 64k as binaries).

I'm thinking we need a place to store icons out of band from the annotations then we can just use links in the annotations. I guess anyone can plugin in a microservice to do this at any time (we did this months ago with our app library in fabric8) but I'd love to have some standard canonical way for a template author or installer to put them and to minimise the number of moving pieces

[liggitt]

we could allow putting an actual network URL in the icon annotation (it's a URL already, just a data: URL)... there were just implications we hadn't fully thought through, so we didn't enable that immediately:

1. mixed-mode errors (or blocked icon loads) if the console is https and the url is http
2. security implications of loading images from remote URLs specified in templates