provide an 'openshift override' enricher

its common to have to wire things up differently on openshift versus kubernetes; we’ve found this on the fabric8 platform project; we’ve been making a fair use of the annotations: fabric8.io/target-platform: "kubernetes" and fabric8.io/target-platform: "openshift" then copy/pasting entire YAMLs.

It would be nice to make the markup much more DRY and easier to reason about the differences between the kubernetes and openshift flavours.

e.g. what would be cooler would be to leave the src/main/fabric8 folder as the default kubernetes markup; then have YAML fragments that get applied to override values for the openshift platform flavour. e.g. files in, say, src/main/fabric8/openshift or src/main/fabric8/platform/openshift would then override the contents of src/main/fabric8.

here are 2 simple examples

• https://github.com/fabric8io/fabric8-platform/blob/master/apps/forge/src/main/fabric8/cm.yml
• https://github.com/fabric8io/fabric8-platform/blob/master/apps/forge/src/main/fabric8/openshift-cm.yml

what would be nice would be just to provide the overrides for openshift without having to copy/paste it all:

e.g. instead of

apiVersion: v1
kind: ConfigMap
metadata:
  name: forge
  annotations:
    fabric8.io/target-platform: "openshift"
    expose.config.fabric8.io/apiserver-url-key: apiserver.url
    #expose.service-key.config.fabric8.io/sso: keycloak.url
data:
  keycloak.url: http://keycloak
  apiserver.url: http://kubernetes

we could just define the overrides:

metadata:
  name: forge
  annotations:
    expose.service-key.config.fabric8.io/sso: 
data:
  keycloak.url: http://keycloak

(where the empty annotation removes the annotation for the openshfit.yml)

e.g. here’s 2 files we’re using for the console which are mostly the same apart from an environment variable (I think)

• https://github.com/fabric8io/fabric8-platform/blob/master/apps/fabric8/src/main/fabric8/deployment.yml
• https://github.com/fabric8io/fabric8-platform/blob/master/apps/fabric8/src/main/fabric8/dc.yml

but its kinda hard to grok the delta really; they should be mostly the same

[jstrachan]

@rhuss I could really use this feature before we find time to implement 4.x - its desperately required for fabric8 upstream to avoid copy/paste hell 😃

For now where would you suggest we put the override files? src/main/fabric8-openshift maybe? Then any partials in that folder would be used to override anything in the kubernetes-centric stuff in src/main/fabric8?

My requirements are pretty simple right now - I just wanna override a few annotations here or there and the odd data entry in a ConfigMap for OpenShift

Whenever 4.x comes along we can refactor this to load the relevant files in the right pass through the enrichers and whatnot

[rhuss]

“new enricher architecture” is present in 3.5 version or its part of f8-m-p v.4 (fmp 4) release?

It’s part of fmp v4 (at least as I envision it 😉. See also https://github.com/fabric8io/fabric8-build for some more information about the refactoring and https://github.com/fabric8io/fabric8-maven-plugin/issues/678

Apart from overriding, how to treat if OpenShift overriding fragment contains additional annotation properties?

I would say, that they were simply added.