eclipse-jkube · manusa · Apr 29, 2021 · Apr 15, 2021
@@ -35,6 +35,7 @@ Usage:
 * Fix #679: Quarkus package detection improvements
 * Fix #622: Corrected documentation for `jkube-healthcheck-karaf`
 * Fix #630: DeploymentConfigEnricher and DefaultControllerEnricher refactored and aligned
+* Fix #639: Quotas for OpenShift BuildConfig not working
 
 ### 1.2.0 (2021-03-31)
 * Fix #529: `.maven-dockerignore`, `.maven-dockerexclude`, `.maven-dockerinclude` are no longer supported

@@ -57,12 +57,21 @@ This plugin comes with a set of default enrichers. In addition custom enrichers
 | <<jkube-dependency>>
 | Examine build dependencies for `kubernetes.yml` and add the objects found therein.
 
+| <<jkube-docker-registry-secret>>
+| Add a `Secret` for your Docker registry credentials.
+
 | <<jkube-git>>
 | Check local `.git` directory and add build information as annotations.
 
 | <<jkube-image>>
 | Add the image name into a `PodSpec` of replication controller, replication sets and deployments, if missing.
 
+| <<jkube-ingress>>
+| Create a default Ingress if missing or configured from XML configuration
+
+| <<jkube-metadata>>
+| Add labels/annotations to generated Kubernetes resources
+
 | <<jkube-maven-issue-mgmt-enricher>>
 | Add Maven Issue Management information as annotations to the kubernetes/openshift resources
 
@@ -116,17 +125,41 @@ include::enricher/_jkube_container_env_java_options.adoc[]
 
 include::enricher/_jkube_controller.adoc[]
 
-include::enricher/_jkube_service.adoc[]
+[[jkube-dependency]]
+==== jkube-dependency
+
+[[jkube-docker-registry-secret]]
+==== jkube-docker-registry-secret
+
+This enricher enables {goal-prefix}:resource Secret generation feature. You can read more about it <<resource-secrets, Secrets>>.
+
+include::enricher/_jkube_git.adoc[]
 
 [[jkube-image]]
 ==== jkube-image
 
+[[jkube-ingress]]
+==== jkube-ingress
+
+This enricher is responsible for generating Ingress resource during {goal-prefix}:resource goal. You can read more about it in <<ingress-generation, Ingress Generation>> section.
+
+[[jkube-metadata]]
+==== jkube-metadata
+This enricher is responsible for adding labels and annotations to your resources. It reads `<labels>` and `<annotations>` fields provided in `<resources>` and adds respective labels/annotations to Kubernetes resources.
+
+You can also configure whether you want to add these labels/annotations to some specific resource or all resources. You can see an example if it's usage in {goal-prefix}:resource <<resource-labels-annotations, Labels And Annotations>> section.
+
+include::enricher/_jkube_maven_scm_enricher.adoc[]
+
+include::enricher/_jkube_maven_issue_mgmt.adoc[]
+
 [[jkube-name]]
 ==== jkube-name
 
-[[jkube-namespace]]
 include::enricher/_jkube_namespace.adoc[]
 
+include::enricher/_jkube_openshift_autotls.adoc[]
+
 [[jkube-portname]]
 ==== jkube-portname
 
@@ -135,30 +168,23 @@ include::enricher/_jkube_namespace.adoc[]
 
 include::enricher/_jkube_project_label.adoc[]
 
-include::enricher/_jkube_git.adoc[]
-
-[[jkube-dependency]]
-==== jkube-dependency
-
-include::enricher/_jkube_volume_permission.adoc[]
-
-include::enricher/_jkube_openshift_autotls.adoc[]
-
 include::enricher/_jkube_prometheus.adoc[]
 
-include::enricher/_jkube_maven_scm_enricher.adoc[]
-
-include::enricher/_jkube_maven_issue_mgmt.adoc[]
-
 include::enricher/_jkube_revision_history.adoc[]
 
-include::enricher/_jkube_triggers_annotation.adoc[]
-
 include::enricher/_jkube_secret_file.adoc[]
 
+include::enricher/_jkube_service.adoc[]
+
 [[jkube-serviceaccount]]
 ==== jkube-serviceaccount
 
+This enricher is responsible for creating ServiceAccount resource. See <<serviceaccount-generation, ServiceAccount Generation>> for more details.
+
+include::enricher/_jkube_triggers_annotation.adoc[]
+
+include::enricher/_jkube_volume_permission.adoc[]
+
 [[enrichers-specific]]
 === Specific Enrichers
 

@@ -234,7 +234,7 @@ The plugin configuration can be roughly divided into the following sections:
 * `<images>` defines which Docker <<image-configuration,images>> are used and configured. This section is similar to the
    https://dmp.fabric8.io//#image-configuration[image configuration] of the `docker-maven-plugin`, except that `<run>`
    and `<external>` sub-elements are ignored)
-* `<resource>` defines the resource descriptors for deploying on an OpenShift or Kuberneres cluster.
+* `<resources>` defines the resource descriptors for deploying on an OpenShift or Kubernetes cluster.
 * `<generator>` configures <<generators,generators>> which are responsible for creating images. Generators are used as an alternative to a dedicated `<images>` section.
 * `<enricher>` configures various aspects of <<enrichers,enrichers>> for creating or enhancing resource descriptors.
 
@@ -284,11 +284,44 @@ An extract of the plugin configuration is shown below:
       </service>
     </services>
 
-    <serviceAccounts>
+    <serviceAccounts> <!--7-->
       <serviceAccount>
         <name>build-robot</name>
       </serviceAccount>
     </serviceAccounts>
+
+    <annotations> <!--8-->
+      <all>
+        <version>${project.version}</version>
+        <artifactId>${project.artifactId}</artifactId>
+      </all>
+      <deployment> <!--9-->
+        <my>deployment</my>
+      </deployment>
+    </annotations>
+
+    <configMap> <!--10-->
+      <name>test</name>
+      <entries>
+        <entry> <!--11-->
+          <name>key1</name>
+          <value>value1</value>
+        </entry>
+        <entry> <!--12-->
+          <name>key3</name>
+          <file>${project.basedir}/src/main/resources/META-INF/resources/index.html</file>
+        </entry>
+      </entries>
+    </configMap>
+
+    <liveness> <!--13-->
+      <getUrl>http://localhost:8080/q/health</getUrl>
+      <initialDelaySeconds>3</initialDelaySeconds>
+      <timeoutSeconds>3</timeoutSeconds>
+    </liveness>
+    <remotes> <!--14-->
+       <remote>https://gist.githubusercontent.com/lordofthejars/ac2823cec7831697d09444bbaa76cd50/raw/e4b43f1b6494766dfc635b5959af7730c1a58a93/deployment.yaml</remote>
+    </remotes>
   </resources>
 </configuration>
 ----
@@ -298,6 +331,14 @@ An extract of the plugin configuration is shown below:
 <4> Number of replicas desired
 <5> Name of controller created by plugin
 <6> One or more http://kubernetes.io/docs/user-guide/services/[Service] definitions.
+<7> ServiceAccount(s) to create
+<8> Annotations which should be applied either to all or to specific resources
+<9> Annotations applied to Deployment resources only
+<10> ConfigMap to be created
+<11> ConfigMap data entry as a string key value pair
+<12> ConfigMap data entry with value as file path, file's contents are loaded into ConfigMap as key value
+<13> Liveness Probe to be added in PodTemplateSpec of Controller resource
+<14> Remote files used as resource fragments.
 
 The XML resource configuration is based on plain Kubernetes resource objects. When targeting OpenShift, Kubernetes resource descriptors will be automatically converted to their OpenShift counterparts, e.g. a Kubernetes http://kubernetes.io/docs/user-guide/deployments/[Deployment] will be converted to an OpenShift https://docs.openshift.com/container-platform/4.1/applications/deployments/what-deployments-are.html#deployments-and-deploymentconfigs_what-deployments-are[DeploymentConfig].
 

@@ -47,6 +47,41 @@ You can also use `file` tag to refer to the content of a file.
 This creates a ConfigMap with key `test-application.properties` and value the content of the `src/test/resources/test-application.properties` file.
 If you set `name` tag then this is used as key instead of the filename.
 
+[[configmap-xml-configuration]]
+===== ConfigMap XML Configuration
+Here are the supported options while providing `<configMap>` in XML configuration
+
+.XML configmap configuration`<configMap>`
+[cols="1,5"]
+|===
+| Element | Description
+
+| <<configmap-entry-xml-configuration, `entries`>>
+| data for ConfigMap
+
+| `name`
+| Name of the ConfigMap
+|===
+
+[[configmap-entry-xml-configuration]]
+===== ConfigMap Entry XML Configuration
+`<entries>` is a list of `<port>` configuration objects. Here are the supported options while providing `<entry>` in XML configuration
+
+.XML configmap entry configuration`<entry>`
+[cols="1,5"]
+|===
+| Element | Description
+
+| `value`
+| Entry value
+
+| `file`
+| path to a file or directory. If it's a single file then file contents would be read as value. If it's a directory then each file's content is stored as value with file name as key.
+
+| `name`
+| Entry name
+|===
+
 If you are defining a custom `ConfigMap` file, you can use an annotation to define a file name as key and its content as the value:
 
 [source, yaml]
@@ -69,4 +104,4 @@ metadata:
     maven.jkube.io/cm/application.properties: src/test/resources/test-dir
 ----
 
-This creates a `ConfigMap` named `application.properties` (part defined after `cm`) and for each file under the directory `test-dir` one entry with file name as key and its content as the value; subdirectories are ignored.
+This creates a `ConfigMap` named `application.properties` (part defined after `cm`) and for each file under the directory `test-dir` one entry with file name as key and its content as the value; subdirectories are ignored.
@@ -21,3 +21,16 @@ The following configuration parameters can be used to influence the behaviour of
   Defaults to `Namespace`.
 | `jkube.enricher.jkube-namespace.type`
 |===
+
+This enricher also configures generated Namespace in `.metadata.namespace` field for Kubernetes resources as per provided XML configuration too. Here is an example:
+
+[source,xml]
+----
+<configuration>
+    <resources>
+        <namespace>mynamespace</namespace>
+    </resources>
+</configuration>
+----
+
+
@@ -158,3 +158,67 @@ This example shows also the mapping rules:
 Multiple ports are **only** mapped when _multiPort_ mode is enabled (which is switched off by default). If _multiPort_ mode is disabled, only the first port from the list of mapped ports calculated as above is taken.
 
 When you set `legacyPortMapping` to true than ports 8080 to 9090 are mapped to port 80 automatically if not explicitly mapped via `_port_`. I.e. when an image exposes port 8080 with a legacy mapping this mapped to a service port 80, not 8080. You _should not_ switch this on for any good reason. In fact it might be that this option can vanish anytime.
+
+This enricher is also used by `<resources>` XML configuration to generate Service configured via XML. Here are the fields supported in `<resources>` which work with this enricher:
+
+.Fields supported in `<resources>`
+[cols="1,5"]
+|===
+| Element | Description
+| <<service-xml-configuration, `services`>>
+| Configuration element for generating Service resource
+|===
+
+[[service-xml-configuration]]
+===== Service XML Configuration
+`<services>` is a list of `<service>` configuration objects. Here are the supported options while providing `<service>` in XML configuration
+
+.XML `<service>` configuration
+[cols="1,5"]
+|===
+| Element | Description
+
+| `name`
+| Service name
+
+| `port`
+| Port to expose
+
+| `headless`
+| Whether this is a headless service.
+
+| `type`
+| Service type
+
+| `normalizePort`
+| Whether to normalize service port numbering.
+
+| <<service-port-xml-configuration, `ports`>>
+| Ports to expose
+|===
+
+[[service-port-xml-configuration]]
+===== Service `<port>` Configuration
+`<ports>` is a list of `<port>` configuration objects. Here are the supported options while providing `<port>` in XML configuration
+
+.XML service port configuration
+[cols="1,5"]
+|===
+| Element | Description
+
+| `protocol`
+| Protocol to use. Can be either "tcp" or "udp".
+
+| `port`
+| Container port to expose.
+
+| `targetPort`
+| Target port to expose.
+
+| `nodePort`
+| Port to expose from the port.
+
+| `name`
+| Name of the port
+|===
+
@@ -72,6 +72,51 @@ The configuration consists of two parts:
 Many of the options below are relevant for the <<build-kubernetes, Kubernetes Workflow>> or the <<build-openshift, OpenShift Workflow>> with Docker builds as they influence how the Docker image is build.
 
 For an S2I binary build, on the other hand, the most relevant section is the <<build-assembly, Assembly>> one because the build depends on which buider/base image is used and how it interprets the content of the uploaded `docker.tar`.
+
+[[setting-quota-openshift-build]]
+==== Setting Quotas for OpenShift Build
+You can also limit resource use by specifying resource limits as part of the build configuration. You can do this by providing `<openshiftBuildConfig>` field in `<resource>` configuration. Below is an example on how to do this:
+
+.Example of OpenShift S2I Build resource/limit Configuration
+[source,xml]
+----
+<configuration>
+    <resources>
+         <openshiftBuildConfig>
+            <requests> <!--1-->
+              <cpu>500m</cpu> <!--2-->
+              <memory>512Mi</memory> <!--3-->
+            </requests>
+            <limits> <!--4-->
+              <cpu>1000m</cpu> <!--5-->
+              <memory>1Gi</memory> <!--6-->
+            </limits>
+         </openshiftBuildConfig>
+    </resources>
+</configuration>
+----
+
+<1> Request field which maps to created BuildConfig's `.spec.resources.requests`
+<2> Minimum CPU required by Build Pod
+<3> Minimum memory required by Build Pod
+<4> Limits field which maps to created BuildConfig's (`.spec.resources.limits`)
+<5> Maximum CPU required by Build Pod
+<6> Maximum memory required by Build Pod
+
+It's also possible to provide a `buildconfig.yml` BuildConfig resource fragment in `src/main/jkube` directory like this:
+
+.BuildConfig fragment Example(`buildconfig.yml`)
+[source,yaml]
+----
+spec:
+  resources:
+    limits:
+      cpu: "600m"
+      memory: "512Mi"
+    requests:
+      cpu: "500m"
+      memory: "300Mi"
+----
 endif::[]
 
 [[build-goal-configuration]]