we should default to Deployment OOTB I would think really as its the k8s standard and has rolling upgrades baked in etc

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 fabric8io/fabric8#5861

so we can't release the generated kubernetes.yml.

At the moment on plain Kubernetes objects are created. When running in
OpenShift mode the template handling should be introduced.

In contrast to the old implementation where the template is created
first and then, if pure Kubernetes objects are requested, the template
is applied locally and objects from non-Kubernetes packages are
removed, the discrimination template yes/no should be done from the
very beginning.

Also it could make sense that even for OpenShift non-template can be
created.

The idea is to have an OpenShiftConfiguration object, inherited from
KubernetesKonfiguration and stored in a member openshift, so that
the discrimnation happens based on the top-level configuration tag

<kubernetes>
  <services> ...
  ...
</kubernetes>

vs

<openshift>
  <useTemplates>true</useTemplates>

<openshift>

with useTemplates == true being the default. (useTemplates is then
also only available for <openshift>

In case a service port has been autodetected lookup the IANA service name from http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

This could be done by prefetching the association and store it in a serialized hash map which is stored in the jar file, if not too large. Optimization could be done by sharding via port range (so multiple serialized hash maps).

e.g. KUBERNETES_NAMESPACE should get defaulted across

if you use 1.0-SNAPSHOT as the docker image name, then deploy it with mvn fabric8:deploy then the second time you build you often get docker failures due to the image label being in use.

it'd be nice if OOTB the plugin was smarter & defaulted the docker label to a timestamp label if the ${project.version} ends with SNAPSHOT; so that the same timestamp is exposed in the kubernetes resource as is created via fabric8:build

e.g. I've a use case to just mount a volume only; but happy to reuse the OOTB defaulting of the container spec

Its kinda hard to read a kubernetes list when there's a bunch of resources inside (SA / Service / RC et al).

Its much easier to just look at individual files. I wonder if by default we should generate individual files from the kubernetes.yml so that if you're looking at the generation of, say, foo-rc.yml then you can look at target/fabric8/kubernetes/foo-rc.yml to see the fully enriched generated file?

The icon handling via annotations needs to be readded in a dedicated enricher, enabled by default.

it looks like if you create a DeploymentConfig with annotations they are lost from the RC that gets created. Am not sure if the same is true for Deployment -> RS yet; but we should probably copy annotations from a Deployment(Config).metadata.annotations -> spec.template.metadata.annotations

I guess this is a customizer?

e.g. after a local build:

cd sample/spring-boot
mvn clean compile
cat target/classes/META-INF/fabric8/spring-boot-web-rs.yml

generates

---
apiVersion: "extensions/v1beta1"
kind: "ReplicaSet"
metadata:
  name: "spring-boot-web"
spec:
  replicas: 1
  template:
    metadata: {}
    spec:
      containers:
      - env:
        - name: "KUBERNETES_NAMESPACE"
          valueFrom:
            fieldRef:
              fieldPath: "metadata.namespace"
        image: "fabric8/spring-boot-web:3.0-SNAPSHOT"
        imagePullPolicy: "IfNotPresent"
        name: "fabric8-spring-boot-web"
        ports:
        - containerPort: 8080
          protocol: "TCP"
        securityContext:
          privileged: false

I wonder if we should have a goal mvn fabric8:run that's the cluster equivalant of mvn spring-boot:run for locally running things which also ensured that the install goal was run?

I've been setting the <defaultGoal/> for funktion stuff to be spring-boot:run for local stuff; wonder if we should add a profile to act as a simple alias for mvn install fabric8:deploy as its quite a mouthful to type.

Not sure of a concise catchy name yet though ;). Any good suggestions?

How about:

mvn -Pf8

I get 2 Service and 2 DC objects:

---
apiVersion: "v1"
items:
- apiVersion: "v1"
  kind: "Service"
  metadata:
    annotations:
      fabric8.io/iconUrl: "data:text/plain;charset=UTF-8;base64,cm91dGVzLnhtbAo="
      prometheus.io/scrape: "true"
      prometheus.io/port: "9779"
    labels:
      project: "springboot-camel-xml"
      provider: "fabric8"
      version: "1.0-SNAPSHOT"
      group: "io.fabric8.quickstarts"
    name: "springboot-camel-xml"
  spec:
    ports:
    - port: 8080
      protocol: "TCP"
      targetPort: 8080
    selector:
      project: "springboot-camel-xml"
      provider: "fabric8"
      group: "io.fabric8.quickstarts"
- apiVersion: "v1"
  kind: "Service"
  metadata:
    annotations:
      fabric8.io/iconUrl: "data:text/plain;charset=UTF-8;base64,cm91dGVzLnhtbAo="
      prometheus.io/scrape: "true"
      prometheus.io/port: "9779"
    labels:
      project: "springboot-camel-xml"
      provider: "fabric8"
      version: "1.0-SNAPSHOT"
      group: "io.fabric8.quickstarts"
    name: "springboot-camel-xml"
  spec:
    ports:
    - port: 8080
      protocol: "TCP"
      targetPort: 8080
    selector:
      project: "springboot-camel-xml"
      provider: "fabric8"
      group: "io.fabric8.quickstarts"
- apiVersion: "v1"
  kind: "DeploymentConfig"
  metadata:
    annotations:
      fabric8.io/iconUrl: "img/icons/camel.svg"
      fabric8.io/metrics-path: "dashboard/file/camel-routes.json/?var-project=springboot-camel-xml&var-version=1.0-SNAPSHOT"
    labels:
      project: "springboot-camel-xml"
      provider: "fabric8"
      version: "1.0-SNAPSHOT"
      group: "io.fabric8.quickstarts"
    name: "springboot-camel-xml"
  spec:
    replicas: 1
    selector:
      project: "springboot-camel-xml"
      provider: "fabric8"
      group: "io.fabric8.quickstarts"
    template:
      metadata:
        labels:
          project: "springboot-camel-xml"
          provider: "fabric8"
          version: "1.0-SNAPSHOT"
          group: "io.fabric8.quickstarts"
      spec:
        containers:
        - env:
          - name: "KUBERNETES_NAMESPACE"
            valueFrom:
              fieldRef:
                fieldPath: "metadata.namespace"
          image: "quickstarts/springboot-camel-xml:latest"
          imagePullPolicy: "IfNotPresent"
          livenessProbe:
            httpGet:
              path: "/health"
              port: 8081
            initialDelaySeconds: 180
          name: "springboot"
          ports:
          - containerPort: 8080
            protocol: "TCP"
          - containerPort: 9779
            protocol: "TCP"
          - containerPort: 8778
            protocol: "TCP"
          readinessProbe:
            httpGet:
              path: "/health"
              port: 8081
            initialDelaySeconds: 10
          securityContext:
            privileged: false
    triggers:
    - type: "ConfigChange"
- apiVersion: "v1"
  kind: "DeploymentConfig"
  metadata:
    annotations:
      fabric8.io/iconUrl: "img/icons/camel.svg"
      fabric8.io/metrics-path: "dashboard/file/camel-routes.json/?var-project=springboot-camel-xml&var-version=1.0-SNAPSHOT"
    labels:
      project: "springboot-camel-xml"
      provider: "fabric8"
      version: "1.0-SNAPSHOT"
      group: "io.fabric8.quickstarts"
    name: "springboot-camel-xml"
  spec:
    replicas: 1
    selector:
      project: "springboot-camel-xml"
      provider: "fabric8"
      group: "io.fabric8.quickstarts"
    template:
      metadata:
        annotations:
          fabric8.io/iconUrl: "img/icons/camel.svg"
          fabric8.io/metrics-path: "dashboard/file/camel-routes.json/?var-project=springboot-camel-xml&var-version=1.0-SNAPSHOT"
        labels:
          project: "springboot-camel-xml"
          provider: "fabric8"
          version: "1.0-SNAPSHOT"
          group: "io.fabric8.quickstarts"
      spec:
        containers:
        - env:
          - name: "KUBERNETES_NAMESPACE"
            valueFrom:
              fieldRef:
                fieldPath: "metadata.namespace"
          image: "quickstarts/springboot-camel-xml:latest"
          imagePullPolicy: "IfNotPresent"
          livenessProbe:
            httpGet:
              path: "/health"
              port: 8081
            initialDelaySeconds: 180
          name: "springboot"
          ports:
          - containerPort: 8080
            protocol: "TCP"
          - containerPort: 9779
            protocol: "TCP"
          - containerPort: 8778
            protocol: "TCP"
          readinessProbe:
            httpGet:
              path: "/health"
              port: 8081
            initialDelaySeconds: 10
          securityContext:
            privileged: false
    triggers:
    - type: "ConfigChange"
kind: "List"

It should be possible to define the service selector in a more
flexible way. Currently the only possibility is to remove the version
label, however one should possibly either configure the kind of labels
which should be able to remove.

Annotations related to documentation need to be reinserted in an Enricher.

This is a first shot of the new configuration syntax.

The synergy / overlap with d-m-p currently is:

• Docker Image name is shared
• More then one container per pod easily possible: Each d-m-p image with a <build> sections is automatically picked up for the pod template.
• A fabric8:build can create a plain docker image (for Kuberenets) or all what is needed for an OpenShift Build, depending on the operational mode ( #12 )

You might wonder what this enricher stuff is: It's a mean to decouple linkage to other fabric8 projects (like the icon generation for fabric8-console, the secrets handling for fabric8-devops, metrics exposure for prometheus) so that this can be easily switched on / off. It is also meant to complement (or maybe replace in the long run ?) the APT based generation of additional or customised resource objects with the Kubernetes builder). Custom enricher can be added as dependencies (and will be picked up from the compile classpath), much like spring-boot-starters. They have the advantage to be not coupled to the compile step and need no intermediate data file (which could be stale). Its also easy to combine the enrichers with resource object templates from src/main/fabric8.

Here's now the suggestion:

<configuration>
  <!-- Standard d-m-p configuration which defines how images are build, i.e. how the docker.tar is created -->
  <images>
    <image>
      <name>${image.user}/${project.artifactId}:${project.version}</name>
      <!-- "alias" is used to correlate to the containers in the pod spec -->
      <alias>camel-service</alias>
      <build>
        <from>fabric8/java</from>
        <assembly>
          <basedir>/deployments</basedir>
          <descriptorRef>artifact-with-dependencies</descriptorRef>
        </assembly>
        <env>
          <JAVA_LIB_DIR>/deployments</JAVA_LIB_DIR>
          <JAVA_MAIN_CLASS>org.apache.camel.cdi.Main</JAVA_MAIN_CLASS>
        </env>
      </build>
    </image>
  </images>
   <!-- Instead of "kubernetes", "openshift" can be used to switch on openshift mode (create templates,
       use image stream, use binary builds). When "openshift" is used, it has additional configuration to switch
       off openshift features, too) -->
  <kubernetes>
    <!-- Resource directory from where to pick up k8s resource templates which are filled in with
         maven properties and enriched by 'enrichers'-->
    <resourceDir>src/main/fabric8</resourceDir>
    <!-- Labels that are applied to all created objects -->
    <labels>
      <group>quickstarts</group>
    </labels>
    <!-- Configuration of enrichers, which can be switched off with `<skip>true</skip>`-->
    <enricher>
      <!-- Default enrichers for adding labels, annos, etc. are provided by the plugin but
           can be switched off, too -->
      <project-info>
        <skip>false</skip>
      </project-info>
    </enricher>
    <!-- Definition of the ReplicationController / ReplicaSet. Any better name than "containers" ? -->
    <replicaSet>
      <!-- Name of the replication controller, which will have a sane default (container alisa, mvn coords, ..) -->
      <name>${project.artifactId}</name>
      <!-- Replica count-->
      <replicas>1</replicas>
      <!-- Container to include in the POD template. By default all with a "build" section in the
           "images" configuration will be add to the POD. However, they can be configured separately, too.
          -->
      <containers>
        <container>
          <!-- Alias name correlating with the same named "image" configuration above. Can be ommitted
               if there is only a single image added -->
          <alias>camel-service</alias>
          <ports>
            <!-- Ports to ex[ose in the pod specs -->
            <port>8778</port>
          </ports>
          <mounts>
            <scratch>/var/scratch</scratch>
          </mounts>
        </container>
      </containers>
      <!-- Volumes used in the replicaSet -->
      <volumes>
        <volume>
          <name>scratch</name>
          <type>emptyDir</type>
        </volume>
      </volumes>
    </replicaSet>
    <!-- Dedicated section for (multiple) services to define -->
    <services>
      <service>
        <name>${project.artifactId}</name>
        <headless>true</headless>
      </service>
    </services>
  </kubernetes>
</configuration>

In the zero config case, detect if spring-actuator-starter is configured and automatically add health checks to the generated Kubernetes descriptors.

so converting

• ReplicaSet -> ReplicationController
• Deployment -> DeploymentConfig

then lets make mvn fabric8:deploy detect its on openshift and use the openshift.yml instead of the kubernetes.yml

This solves part of #46

Current the configuration is quite simplistic, reusing <build> from the docker configuration and the portmapping from <run>.

Especially the latter probably doesnt make much sense.
Also the question is, whether annotation and label configuration should be done in more nested way. Also, label config is currently global for all objects (as in v2) but could be more fine granular and different for RC, Pods, Services ....

The profile new in the cdi-sample is are some first thoughts about a possible structure. Need still a night :)

... should apply the resource descriptor to the OpenShift API server.

More or less the same as the V2 fabric8:apply.

which if its a kubernetes service, resolve to the external URL. Then replace any ${project.artifactId} or ${project.verison} values so even if the site is hosted outside of kubernetes it works fine

Depending on whether OpenShift is enabled and the build strategy is binary build source then instead of creating a Docker image via the docker daemon the plugin should create

• A docker.tar (like for docker:build or docker:source)
• A BuildConfig object for OpenShift.
• Apply the BuildConfig by contacting API servcer
• Create a Build object, feeding in the docker.tar
• Wait until the build is finished.

The resulting ImageStream should be referenced from within resource descriptors created with fabric8:resource

In the old code there is a section dealing with DeploymentConfigs
however, this was never active. When using openshift mode, it should
be able to use DCs

this is particularly important when using timestamp labels

we currently generate services like this for spring boot:

---
apiVersion: "v1"
kind: "Service"
metadata:
  name: "spring-boot-web"
spec:
  ports:
  - port: 8080
    protocol: "TCP"
    targetPort: 8080

if we have only 1 port its > 1000 and there's no explicit configuration I wonder if we should assume port 80? Or at least we can assume 8080 should be exposed as port 80 by default

right now we create a single json / yaml file which typically is an OpenShift Template or a kubernetes List.

To make things easier to consume we should probably always have a vanilla k8s yaml folks can run.

There are a few options though:

• deliver a few yaml files for each resource (RC / service / SA etc)
• create a zip of the yaml files (easier for integration into things like helm or putting into git repos - uber yaml files are harder to reason about)
• a single k8s yaml file thats easier to install (with things sorted nicely so services are first etc) - using ConfigMaps if we are using parameterisation
• a single OpenShift template yaml file for folks who wanna parameterise things on install time
• a 'Catalog yaml file' when folks want to install the app into a Catalog (think like an App store - like installing an OpenShift Template but so it works on any k8s environmment - we could encode the app inside a Config Map).

I wonder if we should do all of the above by default; coming up with standard maven archetype classifiers so folks can easily consume the things they need; a k8s yaml, an OpenShift Template, individual files or a zip of the files or the Catalog yaml etc?

Catalog resources

Right now we use OpenShift templates as a way of installing a resource into k8s we can then use from the Fabric8 console to run apps via the Run... button. Its just a way of storing a blob of YAML inside k8s for running it later.

Going forward we want to support non-OpenShift templates (some things don't need parameterisation). Plus we wanna support vanilla kubernetes - also there's ConfigMap where there's no OpenShift Template and the parameterisation is done by a separate ConfigMap entry.

So we could maybe use ConfigMap as an alternative to OpenShift templates for the 'catalog' of apps folks could choose to run.

e.g. an app could be turned into this...

apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp
  labels:
     kind: catalog
data:
  service-foo.yml: |
    apiVerison: v1
    kind: Service
    ...
  rc.yml: |
    apiVerison: v1
    kind: Service
    ...

i.e. we create a ConfigMap instead of an OpenShift Template to store all the resources individually (with each file stored inside the config map as a data entry)

The Fabric8 Console's Run... button can then view all the Templates and ConfigMaps in a system to let folks run apps

e.g. to override the spec.type like this

spec:
  type: LoadBalancer

it'd be nice to be able to refer to versions in rc.yml files in image names using a standard maven property expression which is latest when the ${project.version} ends with -SNAPSHOT otherwise it defaults to ${project.version}.

Then folks can use the same expression both for snapshots and real releases

The VolumeConfiguration should be possible to be configurable with

<volumes>
   <persistentVolumeClaim> ... </persistentVolumeClaim>
   <hostPath>  ... </hostPath>
    <hostPath> ... </hostPath>
    ...
</volumes>

using the mechanism described in http://blog.sonatype.com/2011/03/configuring-plugin-goals-in-maven-3/

e.g. I tried this rc.yml file and got errors:

spec:
  replicas: 1
  template:
    spec:
      containers:
        - image: fabric8:gitcontroller:latest
      serviceAccount: gitcontroller

I figured it'd default the metadata.name and containers[0].name values to the ${project.artifactId} but it seems thats not the case right now

it would be nice to generate nice validation error messages if the generated resources are not invalid in any way - linking to the individual generated files in target/classes/META-INF/fabric8/ so that folks can easily see whats wrong. e.g. missing name / image or bad names for services or whatever

so that you can use the same user and label for your sidecar containers. We generally can't just use groupId and artifactId as-is since they need to be modified slightly to be valid docker names. So lets expose those properties so folks can use those properties safely in sidecar image names

Caused by: java.lang.NoClassDefFoundError: org/sonatype/plexus/components/sec/dispatcher/SecDispatcher
    at io.fabric8.maven.docker.util.AuthConfigFactory.decrypt(AuthConfigFactory.java:352)
    at io.fabric8.maven.docker.util.AuthConfigFactory.createAuthConfigFromServer(AuthConfigFactory.java:365)
    at io.fabric8.maven.docker.util.AuthConfigFactory.getAuthConfigFromSettings(AuthConfigFactory.java:216)
    at io.fabric8.maven.docker.util.AuthConfigFactory.createAuthConfig(AuthConfigFactory.java:119)
    at io.fabric8.maven.docker.AbstractDockerMojo.prepareAuthConfig(AbstractDockerMojo.java:312)
    at io.fabric8.maven.docker.AbstractDockerMojo.checkImageWithAutoPull(AbstractDockerMojo.java:356)
    at io.fabric8.maven.docker.AbstractBuildSupportMojo.autoPullBaseImage(AbstractBuildSupportMojo.java:107)
    at io.fabric8.maven.docker.AbstractBuildSupportMojo.buildImage(AbstractBuildSupportMojo.java:68)
    at io.fabric8.maven.docker.BuildMojo.buildAndTag(BuildMojo.java:46)
    at io.fabric8.maven.docker.BuildMojo.executeInternal(BuildMojo.java:38)
    at io.fabric8.maven.plugin.docker.BuildMojo.executeInternal(BuildMojo.java:56)
    at io.fabric8.maven.docker.AbstractDockerMojo.execute(AbstractDockerMojo.java:176)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

Its probably a gotcha when embedding d-m-p into f-m-p.

I'm trying to create a ServiceAccount; there will be all kinds of k8s resources over time. (Ingress, Deployment, ConfigMap and many others).

Right now I get

resource failed: Unknown type 'sa'. Must be one of : svc, rc, rs, service

Lets use the naming convention of files purely to default the kind. Otherwise lets read any other files and assume they must include a kind: Foo statement.

Though we could add sa and cm / configmap as other extensions too I guess; along with deployment

I wonder if this is by design?

Here's a sample app that doesn't have or need a Service but one gets generated anyway
https://github.com/fabric8io/gitcontroller/tree/master/src/main/fabric8

looks like this code is the culprit:
https://github.com/jstrachan/fabric8-maven-plugin/blob/f1e91af32c65504e1df507cca94ddfda03a9e84b/plugin/src/main/java/io/fabric8/maven/plugin/util/KubernetesResourceUtil.java#L125-L125

e.g. it'd be nice to name it just rc.yml or something?

I wonder once we start doing #11 and using yml files in src/main/kubernetes or something; could we configure IDEA to smart complete / validate them?

The hooks for metrics handling must added in an enricher, possibly using the full customize() method.

The compositon of various YAML files created e.g. by annotation processors needs to be added.

Still not sure, where and wehn this should happen. Probably as a post processing step directly from within the ResourceMojos

the old fabric8:json goal used to try detect a file called icon.(jpg|jpeg|png|svg|gif) in src/main/fabric8 and if so annotate the generated Template. The original motivation was to try use data URLs for icons so we could embed them inside the templates. We soon found a single template (e.g. cd-pipeline) could require lots of icons (jenkins / gogs / nexus etc) so soon backed away from embedded data urls to just regular URLs.

As we move away from OS Template as the default output to being either a kubernetes zip of resources; a single kubernetes List or an OpenShift List/Template then we should avoid relying on an OpenShift Template being present to give the icon annotation. Instead we should annotate ServiceAccount / Service / Deployment / ReplicationController / ReplicaSet resources with the icon annotation.

Then it doesn't matter how folks run things; the icons will be preserved. Right now we actually try to find the Template for a Service / RC to find the icon in the console :)

External property loading for labels and environment variables is missing.

Secrets are not yet created or referenced.

in terms of post processing of the rc.yml I can imagine folks wanting to add custom sidecar containers.

One specific example that just came up; there's an Infinispan Server RC.yaml which can be deployed as a remote service. However being a cache you often wanna colocate it inside a pod. So it might be nice to embed the infinispan server RC.yaml inside your apps pod template as another container. (i.e. it just copies the containers across and any volumes or secret annotations etc).

So might be nice to have some way to declaratively describe this operation; or maybe its a custom DSL builder thingy operation to merge in a sidecar container from some other RC yaml (described via mvn coordinates maybe?)

If only a port number is detected, try to guess the service name by looking up IANA service names.

Idea: Create a populate HashMap from

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

(there's an XML option, too), serialize it and store it in the jar. For a lookup, deserialize the JAR into an HashMap object.

Only if not to large (maps could be sharded by port range).

Mojo for attaching the resource descriptor to the build as artefact with classifier