diff --git a/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md b/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
index ea5d70ad567cafc8ecb2916a1d16450ae83aff98..df368c50f764c87a94d9c85cdede7d7fcb4d77f5 100644
--- a/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
+++ b/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
@@ -1,31 +1,38 @@
# Example: Offer Jenkins as a Service via Openslice
+## Design the Jenkins (Resource-Facing) Service
+
Before reading this example please make sure that you went through the [Design Helm as a Service](../design_helmaas.md)
-We will use the ```Kind: Application``` of ArgoCD and create a ResourceFacingServiceSpecification for Jenkins
+In this example, we will use the ```Kind: Application``` of ArgoCD and create a ResourceFacingServiceSpecification (RFSS) for Jenkins. Eventually, we will offer Jenkins as a Service.
1. Go to Service Specifications
2. Create New Specification
- 3. Give a Name, eg. jenkinsrfs
+ 3. Provide a Name, eg. jenkinsrfs
4. Go to Resource Specification Relationships
- 5. Assign ```Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/```
+ 5. Assign **Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/** as a related Resource Specification
+
+> Please note that the *https://10.10.10.144:6443/* part of the Resource Specification's name will vary in different Kubernetes installations.
-Focus now on the characteristics configuration.
+Now, we shall focus on the Characteristics' configuration of the created Service Specification. This can be achieved from the the "Service Specification Characteristics" tab.
+
+Specifically, we need to map the lifecycle of ArgoCD Application (e.g. Progressing, Healthy, etc.) to TMF Resource State (e.g. reserved, active, etc.).
-First we need to map the lifecycle of ArgoCD Application to TMF Resource State
+In ArgoCD, the field **status.health.status** has the value that we need to check (Healty, Progressing, etc) for the lifecycle of the application. This is captured by the **_CR_CHECK_FIELD** characteristic.
+Also, the different ArgoCD lifycycle states must be captured by the respective **_CR_CHECKVAL_xxx** characteristics, as show in the figure below.
-In ArgoCD the field **health.status** has the value that we need to check (Healty, Progressing, etc)
-
+
-The _CR_SPEC can be designed first in a YAML or json editor. Let's see a YAML definition:
+After the state mapping, we must provide the template that ArgoCD will use to deploy the Jenkins HELM Chart as an ArgoCD application. For this, we must populate the **_CR_SPEC** characteristic. The _CR_SPEC can be designed first in a YAML or json editor for better parsing.
+Let's see a YAML definition:
```yaml
apiVersion: argoproj.io/v1alpha1
@@ -42,13 +49,14 @@ spec:
name: in-cluster
source:
repoURL: https://charts.jenkins.io
- targetRevision: 4.6.1
+ targetRevision: 5.3.6
chart: jenkins
helm:
values: |
controller:
- service:
- type: ClusterIP
+ serviceType: ClusterIP
+ persistence:
+ enabled: false
syncPolicy:
automated:
prune: true
@@ -61,24 +69,36 @@ spec:
- PruneLast=true
- RespectIgnoreDifferences=true
```
-
-**NOTICE**
+> **NOTE 1**: The above template assumes that the Jenkins Server will acquire a **ClusterIP**. The user should handle the external exposure and access of the Jenkins Server, depending on its cluster configuration. Also, **persistency of the data is disabled** to facilitate the deployment without the need to define storage classes and volumes, as this serves as an example.
-On each installation OSOM will change the name of the resource in order to be unique (will have a UUID)
+```yaml
+ helm:
+ values: |
+ controller:
+ serviceType: ClusterIP
+ persistence:
+ enabled: false
+```
- ```name: openslice-jenkins```
+> **NOTE 2**: On each installation, OSOM will change the name of the resource in order to be unique (will have a UUID), instead of "openslice-jenkins".
+
+```yaml
+name: openslice-jenkins
+```
- destination namespace that ArgoCD will use is the name ```opencrdtest```
+> **NOTE 3**: The namespace that ArgoCD will use to deploy the Jenkins HELM Chart is the "opencrdtest".
- ```destination:
+ ```yaml
+ destination:
namespace: opencrdtest
```
-**This implies that ArgoCD installs the Jenkins always in the same namespace**
-
-**To avoid this we will create a simple pre-provision rule to change the namespace properly**
+**The latter implies that ArgoCD will always install Jenkins in the same namespace.**
+
+**To avoid this we will create a simple LCM rule (pre-provision) to change the namespace accordingly with a unique ID, generated with every new Service Order.**
+
+The LCM rule can be created from the "Life Cycle Rules" tab, pressing the "Create new rule" button. The following image contains the LCM rule that needs to be created for this purpose:
-See the following image:
@@ -92,56 +112,56 @@ See the following image:
7. Drag-Drop the Service > Context > Current Service Order block and select the ID from the drop-down menu. Attach it to the List block of the previous step.
8. Save the PRE_PROVISION Rule
-# Expose the service to your users
+## Expose the Jenkins (Customer-Facing) Service to the users
-Expose then as CustomerFacingServiceSpecification by using the previous RFSS as Service Specification Relationship
+To expose a service towards the users, the designer must create the respective CustomerFacingServiceSpecification, by using the previously designed RFSS as a related service.
-1. Create a Jenkins service and mark as Bundle and save it
-2. Go to Service Specification Relationships and assign Jenkinsrfs
-3. Add also a Logo if you wish
+1. Go to Service Specifications
+2. Create New Specification
+3. Create a Jenkins service, mark as Bundle (to enable Service Specification Relationships) and save it
+4. Go to the "Service Specification Relationships" tab and assign Jenkinsrfs
+5. (Optionally) Add a logo, from the respective "Logo" tab, if you wish
-Expose it now to a Category and a Catalog to be available for ordering.
+Next, expose it through an already created Service Catalog and Service Category so as to make it visible to the users, thus available for ordering.
-# Order the service
-
-Order the service from the catalog.
-
-
-Soon the order will be completed and the Services will be active
+## Order the service
+Order the service from the assigned Service Catalog > Service Category.
+As soon as the Service Order is in **ACKNOWLEDGED** state, it will be processed and eventually completed rendering the services active, as seen in the figure below:
-# How to access the Jenkins installation:
-
-From the Supporting services of the Service Order, select the ResourceFacingService (jenkinsrfs)
+## Access the Jenkins installation
-The ResourceFacingService has also supporting resources in resource inventory.
+Starting from the Service Order overview and specifically the Order Item #1 tab > Supporting Services, select the ResourceFacingService (jenkinsrfs).
+Accordingly, the ResourceFacingService has supporting resources from the resource inventory. The latter are available through the "Supporting Resources" tab.
-One is the resource reference to the application (e.g. _cr_tmpname_...), the other is a secret (e.g. cr87893...).
+The supporting resources of the Jenkins service are:
-Click to go to the secret resource (This is in the Resource inventory of OpenSlice)
+- A resource reference to the application (e.g. _cr_tmpname_...)
+- A secret resource (e.g. cr87893...).
+Select the secret resource, which will navigate you to the Resource Inventory page of OpenSlice. There, you may find the login credentials encoded as Base64.
-Use them to login in your Jenkins.
+Use a Base64 decoder to parse the credentials and use them to login in your Jenkins installation, through the exposed Jenkis Server UI.
> Exposing Jenkins externally is a matter of cluster configuration and request (nodeport, load balancing, etc), thus is not a topic for this example