Closed rhuss closed 6 years ago
A first suggestion:
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
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 ?
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?
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.
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.
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):
zipkin-web-admin-svc.yaml
:spec:
ports:
- port: 9900
protocol: "TCP"
targetPort: 9900
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"
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:
${project.groupId}
/ ${project.artifactId}
/ ${project.version}
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)
BTW I've been using some sample enrichers in this project here:
its working great!
This issue is obsolete with the support for fragments.
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