Pickup and enrichment of external YAML / JSON files

[rhuss]

In the fabric8 directory src/main/fabric8 it should be possible to handcraft resource descriptors which then can be enriched the same way as the descriptors defined within the plugin. Also, a set of properties for templating should be predefined (like the image name).

The boundary is not yet clear and needs to be evaluated.

This is the issue for https://github.com/fabric8io/fabric8/issues/5861

[rhuss]

A first suggestion:

• File: zipkin-web-admin-svc.yaml :

apiVersion: v1
kind: Service
metadata:
  labels:
    # Extension points are annotated with @ServiceLabels, @RcLabels, @RcAnnotations, ...
    # Possible in `@` is not a valid characted in Kubernetes
    @ServiceLabels: { } 
  # Name inferred from file name, but can be given explicitly, too
  # name: "zipkin-web-admin"
spec:
  ports:
  - port: 9900
    protocol: "TCP"
    targetPort: 9900
  selector:
    @ServiceSelector:
      noVersion: true

• File zipkin-web-rc.yml :

apiVersion: "v1"
kind: "ReplicationController"
metadata:
  # If not "annotations" section is given, add the default set. Same 
  # for "labels"
  annotations:
    @RcAnnotations:
      # Fine tuned configuration of how to 'enrich' 
      gitInfo: true
  labels:
    @RcLabels: {}
  # Name can be infered from file name  
  # name: "zipkin-web"
spec:
  # Plain Maven property resolution
  replicas: ${replicaCount}
  selector:
    # Default selector uses all labels of the RC itelf
    @RcSelector: {}
  template:
    metadata:
      annotations: {}
      labels:
        @RcPodLabels: {}
    spec:
      containers:
      - env:
        # Template parameters can be inserted in which case the generation 
        # mode switcheds to 'template' (if not already configured) and all objects 
        # are wrapped into a template structure. Uses a special property syntax #{ ... }
        - name: "TEMPLATE_PARAMETER"
          value: "#{TEMPL_PARAM:default value}"
        - name: "QUERY_PORT_9411_TCP_ADDR"
          value: "zipkin-query-api"
        - name: "TRANSPORT_TYPE"
          value: "http"
        # Infer namespace from meta data and set it as env  
        - @PodEnv
            withNamespace: true
        # Image name can be infered via the RC Name if there is
        # a d-m-p image config with alias 'zipkin-web'. Or it 
        # can be set explicitely with a propertu
        # image: "openzipkin/zipkin-web:1.37.0"
        #
        # Name defaults RC name
        # name: "zipkin-web"

@jstrachan @davsclaus @jimmidyson @iocanel @rawlingsj wdyt ?

[jstrachan]

In general they look good; but I didn't grok what @ServiceSelector and @RcSelector are & why a developer would type them into their yml file?

[rhuss]

By default the selector uses all labels, but e.g. for the @ServiceSelector there is the (sensible) configuration option to omit the version in the set of selector labels.

So the idea is, if no selector is specified, the plugin adds a selector with all labels. If a selector annotation is given (with a possible configuration like the 'noVersion: true' for the service selector), then this can refine or define the selector.

In general most annotations can be omitted in which case the default set of additional labels/annos are added.

[rhuss]

Also for ReplicaSets the selector can be more flexible. Not sure whether we need a dedicated @ServiceSelector annotation or whether we should stick to the the @ServiceLabel for now, with options to omit certain keys.

[rhuss]

The example above is a bit lengthy in order to show the possibilities. In this specific use case here, the shortest way to write the descriptors would be (if the name and the kind is extracted from the file name):

• File: zipkin-web-admin-svc.yaml :

spec:
  ports:
  - port: 9900
    protocol: "TCP"
    targetPort: 9900

• File zipkin-web-rc.yml :

spec:
  replicas: ${replicaCount}
  template:
    spec:
      containers:
      - env:
        - name: "QUERY_PORT_9411_TCP_ADDR"
          value: "zipkin-query-api"
        - name: "TRANSPORT_TYPE"
          value: "http"

[jstrachan]

sounds good; so the @Foo are annotations we can use to write Java code to generate in post processors?

I figured a really common 80% for lots of folks would be:

• omit things (like labels) and have OOTB defaults using ${project.groupId} / ${project.artifactId} / ${project.version}
• folks use the above expressions themselves (or other maven property values)
• as you showed above, we use a 'template property expression' syntax. I guess with ConfigMap coming along the need to use OpenShift template expressions goes away a little; we can bind env vars to ConfigMap values more easily now just using static yaml - but I can see some folks still wanting templates

Then we have a few post processors that add in extra annotations here or there (e.g. adding git url / sha / jenkins build links and stuff)

[jstrachan]

BTW I've been using some sample enrichers in this project here:

• service enrichment: https://github.com/jstrachan/springboot-config-demo/blob/master/src/main/fabric8/service.yml
• deployment/RC/RS enrichment: https://github.com/jstrachan/springboot-config-demo/blob/master/src/main/fabric8/deployment.yml

its working great!

[rhuss]

This issue is obsolete with the support for fragments.