diff --git a/docs/CRIDGEforDevelopers.md b/docs/CRIDGEforDevelopers.md
index 39815a40978dfb42244a0a01eb1493dc8c26a6c1..ab4ce7062c8a22241b2d59f5a3884a2c7881513f 100644
--- a/docs/CRIDGEforDevelopers.md
+++ b/docs/CRIDGEforDevelopers.md
@@ -1,5 +1,7 @@
# CRIDGE: A Service to manage Custom Resources in a Kubernetes Cluster
+
+## Intended Audience: OSL developers
> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box. Custom Resource Definitions (CRDs) is a way that allows to manage things other than Kubernetes itself and allows to create our own objects The use of CRDs makes the possibilities of Kubernetes management almost limitless. You can extend the base Kubernetes API with any object you like using CRDs.
@@ -151,32 +153,11 @@ The sync process is found in the code and explained by the following picture:
- Watchers are created for this namespace for e.g. new secrets, config maps etc , so that they can be available back as resources to the Inventory of OSL (Note only Secrets for now are watched)
-# Expose CRD based service specs for users in catalog
-
-- A CRD is exposed as a Resource Specification
- - Many attributes of the CRD are translated into characteristics
- - The following specific characteristics are added:
- - _CR_SPEC: Used for providing the json Custom Resource description to apply
- - _CR_CHECK_FIELD: Used for providing the field that need to be checked for the resource status
- - _CR_CHECKVAL_STANDBY: Used for providing the equivalent value from resource to signal the standby status
- - _CR_CHECKVAL_ALARM: Used for providing the equivalent value from resource to signal the alarm status
- - _CR_CHECKVAL_AVAILABLE: Used for providing the equivalent value from resource to signal the available status
- - _CR_CHECKVAL_RESERVED: Used for providing the equivalent value from resource to signal the reserved status
- - _CR_CHECKVAL_UNKNOWN: Used for providing the equivalent value from resource to signal the unknown status
- - _CR_CHECKVAL_SUSPENDED: Used for providing the equivalent value from resource to signal the suspended status
-- Create a new Service Specification and use this Resource Specification in Resource Specification Relationships
- - Then the Service Specification is saved as ResourceFacingServiceSpecification
-- We can give at this stage values to the characteristics:
- - _CR_SPEC, _CR_CHECK_FIELD, _CR_CHECKVAL_STANDBY, _CR_CHECKVAL_ALARM, _CR_CHECKVAL_AVAILABLE, _CR_CHECKVAL_RESERVED, _CR_CHECKVAL_UNKNOWN, _CR_CHECKVAL_SUSPENDED
-- We can create LCM rules
-- Create a new Service Specification and use the Resource Facing Service Specification in Service Specification Relationships
- - Then the Service Specification is saved as CustomerFacingServiceSpecification
-- We can give at this stage values to the characteristics:
- - _CR_SPEC, _CR_CHECK_FIELD, _CR_CHECKVAL_STANDBY, _CR_CHECKVAL_ALARM, _CR_CHECKVAL_AVAILABLE, _CR_CHECKVAL_RESERVED, _CR_CHECKVAL_UNKNOWN, _CR_CHECKVAL_SUSPENDED
-- We can create LCM rules for this new Service Specification
-- Expose configurable values for users to configure during service order
-
-<img src="img06.png" width=1024px>
+# Expose CRDs as Service Specifications in OpenSlice catalogs
+
+See [ExposingKubernetesResources](ExposingKubernetesResources.md)
+
+
# Service Orchestration and CRDs/CRs
@@ -245,6 +226,7 @@ and automating operational tasks.
- Assume the following simple CRD of a calculator model accepting two params (spec section) and an action and returning a result (status section)
- The controller (the calculato code) is implemented in any language and is installed in a Kubernetes cluster
+
```
apiVersion: apiextensions.k8s.io/v1
@@ -360,7 +342,7 @@ As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or
```
-=======
+
> LCM rules can be used to change attributes of this yaml/json file, before sending this before the orchestration
However, the following issue needs to be solved: ** How to map the CR lifecycle that is defined in the CRD with the TMF resource Lifecycle? **
@@ -400,215 +382,14 @@ OSOM sends to CRIDGE a message with the following information:
- It sends to the message bus the current resource for creation or update to the TMF service inventory
---
-# Example CRD and its controller
-To illustrate the powerful concept of Kubernetes operators and how they can be utilized to offer a service through OpenSlice,
-let's provide an example of a "Calculator as a Service."
-This example will demonstrate the flexibility and capabilities of Kubernetes operators in managing custom resources
-and automating operational tasks.
+## What's next?
----
-## Offering "Calculator as a Service" through OpenSlice
-
-- We have a service that can accept two integers and an action (SUM, SUB, etc) and returns a result
-- We would like to offer it as a Service through OpenSlice
-- So when a user orders it with some initial parameters, OpenSlice will create it and return the result
-- Also while the service is active, we can do further calculations, until we destroy it.
+ - See examples of exposing operators via OpenSlice:
+ - [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](ExposingCRDs_aaS_Example_Calculator.md)
+
+
+
+
-- Assume the following simple CRD of a calculator model accepting two params (spec section) and an action and returning a result (status section)
-- The controller (the calculato code) is implemented in any language and is installed in a Kubernetes cluster
-
-```
-
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
- name: mycalculators.examples.osl.etsi.org
-spec:
- group: examples.osl.etsi.org
- names:
- kind: MyCalculator
- plural: mycalculators
- singular: mycalculator
- scope: Namespaced
- versions:
- - name: v1alpha1
- schema:
- openAPIV3Schema:
- properties:
- spec:
- properties:
- parama:
- type: integer
- paramb:
- type: integer
- action:
- type: string
- type: object
- status:
- properties:
- result:
- type: integer
- status:
- type: string
- type: object
- type: object
- served: true
- storage: true
- subresources:
- status: {}
-```
-
-
-Request to the cluster (through e.g. kubectl apply)
-
-```
-apiVersion: examples.osl.etsi.org/v1alpha1
-kind: MyCalculator
-metadata:
- name: mycalculator.examples.osl.etsi.org
-spec:
- parama: 170
- paramb: 180
- action: 'SUM'
-
-```
-
-Response
-
-```
-apiVersion: examples.osl.etsi.org/v1alpha1
-kind: MyCalculator
-metadata:
- creationTimestamp: '2023-12-05T12:26:07Z’
-
-<snip>
-
-status:
-Â result: 350
-Â status: CALCULATED
-spec:
-Â action: SUM
-Â parama: 170
-Â paramb: 180
-
-```
-
-To perform this through OpenSlice as a Service Specification ready to be ordered we need to do the following:
-
----
-### CRD is saved automatically as Resource Specification
-
-As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or via any installation through the internet) it is automatically transformed and is available in OpenSlice catalogs as a Resource Specification.
-- See also the fully qualified name of the resource specification.
-- The resource specification name is quite unique, so you can install the CRD in many clusters around the internet. Each CRD on each cluster will appear here
-
-
-<img src="img07.png" >
-
-
-<img src="img08.png" width=1024px>
-
----
-### Create a ResourceFacingServiceSpecification
-
-
-<img src="img09.png" width=1024px>
-<img src="img10.png" width=1024px>
-
-
-
-
-### Creation of CRD-related characteristics
-
-- We need now to adjust some characteristics of this CRD as Resoruce Specification.
-- OpenSlice transalted automatically the CRD spec in a flat list of characteristics.So the "spec" section from the original yaml for example, is now unfold into: spec, spec.parama, spec.paramb, etc. the same for "status" object
-- We need to make OpenSlice aware of when the service will be active.
- - So we go to characteristic _CR_CHECK_FIELD and we define that the field that shows the status of the service is the characteristic "status.status" (is a text field)
- - Then we go to _CR_CHECKVAL_AVAILABLE and we define the value CALCULATED, which signals the following: When the characteristic "status.status" has the value "CALCULATED" then OpenSlice will mark the underlying service as "ACTIVE"
- - We need also to define the yaml file that OpenSLice will use to create the new resource in the kubernetes cluster
- - We insert the YAML in the characteristic _CR_SPEC
-
- the _CR_SPEC is: ```
-apiVersion: examples.osl.etsi.org/v1alpha1
-kind: MyCalculator
-metadata:
- name: mycalculator.examples.osl.etsi.org
-spec:
- parama: 170
- paramb: 180
- action: 'SUM'
-
-```
-
-<img src="img11.png" width=1024px>
-
-
-> However the values are fixed. How do we allow a user to pass parameters through OpenSlice
-
-### Pass parameters through OpenSlice
-
-We need to Create LCM rules in ResourceFacingServiceSpecification
-- The goal of the rules is to allow the user to pass parameters to the actual resource towards the cluster.
-- we will create one rule that will pass the parameters just before creating the service (PRE_PROVISION phase)
-- we will create one rule that will pass the parameters while the service is active (SUPERVISION phase)
-- The rules will be the same
-
-<img src="img12.png" width=1024px>
-
-If we see one rule it will look like the following:
-<img src="img13.png" width=1024px>
-
-- We need to change the _CR_SPEC characteristic
-- We use a block that changes a String according to variables
-- See that we have as Input string the YAML string lines
- - see that parama, paramb has a %d (they accept integers), action is %s (accepts a string)
- - See that the variables tha will replace the %d, %d and %s are an list
- - the first %d will be replaced with the value from characteristic spec.parama
- - the second %d will be replaced with the value from characteristic spec.paramb
- - the %s will be replaced with the value from characteristic spec.action
-
-
-
-### Create a CustomerFacingServiceSpecification
-
-We will now expose it to our users by creating a CustomerFacingServiceSpecification
-
-<img src="img14.png" width=1024px>
-
-Expose it then to a catalogue for orders through the Service Categories and Service Catalogs
-
-
-<img src="img15.png">
-
-
-### Order the Service
-
-When a user orders the service, it will look like this:
-
-<img src="img16.png" width=1024px>
-
-
-
-- After the Service Order we have 2 services in service inventory on CFS and on RFS. Both have references to values
-- CRIDGE updates the Resource in Resource Inventory and OSOM updated the Services in Service Inventory
-- The Actual resources are running in the Kubernetes cluster managed by OpenSlice
-- The result is in the characteristic status.result
-
-<img src="img17.png" width=800px>
-
-<img src="img18.png" width=1024px>
-
- ### Modify the running service
-
- The use can modify the service
-
-<img src="img19.png" width=1024px>
-
-- After a while the update is applied to the cluster, the controller will pick up the resource update and patch the resource
-- CRIDGE updates the Resource in Resource Inventory and OSOM updates the Services in Service Inventory
-
-
-<img src="img20.png" width=1024px>
-
\ No newline at end of file
diff --git a/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md b/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
new file mode 100644
index 0000000000000000000000000000000000000000..ea45b9f85015b4deaba18a03bb7b66d2a11071db
--- /dev/null
+++ b/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
@@ -0,0 +1,216 @@
+
+# Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice
+
+## Intended Audience: Service Designers
+
+
+To illustrate the powerful concept of Kubernetes operators and how they can be utilized to offer a service through OpenSlice,
+let's provide an example of a "Calculator as a Service."
+This example will demonstrate the flexibility and capabilities of Kubernetes operators in managing custom resources
+and automating operational tasks.
+
+---
+## Offering "Calculator as a Service" through OpenSlice
+
+- We have a service that can accept two integers and an action (SUM, SUB, etc) and returns a result
+- We would like to offer it as a Service through OpenSlice
+- So when a user orders it with some initial parameters, OpenSlice will create it and return the result
+- Also while the service is active, we can do further calculations, until we destroy it.
+
+
+- Assume the following simple CRD of a calculator model accepting two params (spec section) and an action and returning a result (status section)
+- The controller (the calculato code) is implemented in any language and is installed in a Kubernetes cluster
+
+```
+
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+ name: mycalculators.examples.osl.etsi.org
+spec:
+ group: examples.osl.etsi.org
+ names:
+ kind: MyCalculator
+ plural: mycalculators
+ singular: mycalculator
+ scope: Namespaced
+ versions:
+ - name: v1alpha1
+ schema:
+ openAPIV3Schema:
+ properties:
+ spec:
+ properties:
+ parama:
+ type: integer
+ paramb:
+ type: integer
+ action:
+ type: string
+ type: object
+ status:
+ properties:
+ result:
+ type: integer
+ status:
+ type: string
+ type: object
+ type: object
+ served: true
+ storage: true
+ subresources:
+ status: {}
+```
+
+
+Request to the cluster (through e.g. kubectl apply)
+
+```
+apiVersion: examples.osl.etsi.org/v1alpha1
+kind: MyCalculator
+metadata:
+ name: mycalculator.examples.osl.etsi.org
+spec:
+ parama: 170
+ paramb: 180
+ action: 'SUM'
+
+```
+
+Response
+
+```
+apiVersion: examples.osl.etsi.org/v1alpha1
+kind: MyCalculator
+metadata:
+ creationTimestamp: '2023-12-05T12:26:07Z’
+
+<snip>
+
+status:
+Â result: 350
+Â status: CALCULATED
+spec:
+Â action: SUM
+Â parama: 170
+Â paramb: 180
+
+```
+
+To perform this through OpenSlice as a Service Specification ready to be ordered we need to do the following:
+
+---
+### CRD is saved automatically as Resource Specification
+
+As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or via any installation through the internet) it is automatically transformed and is available in OpenSlice catalogs as a Resource Specification.
+- See also the fully qualified name of the resource specification.
+- The resource specification name is quite unique, so you can install the CRD in many clusters around the internet. Each CRD on each cluster will appear here
+
+
+<img src="img07.png" >
+
+
+<img src="img08.png" width=1024px>
+
+---
+### Create a ResourceFacingServiceSpecification
+
+
+<img src="img09.png" width=1024px>
+<img src="img10.png" width=1024px>
+
+
+
+
+### Creation of CRD-related characteristics
+
+- We need now to adjust some characteristics of this CRD as Resoruce Specification.
+- OpenSlice transalted automatically the CRD spec in a flat list of characteristics.So the "spec" section from the original yaml for example, is now unfold into: spec, spec.parama, spec.paramb, etc. the same for "status" object
+- We need to make OpenSlice aware of when the service will be active.
+ - So we go to characteristic _CR_CHECK_FIELD and we define that the field that shows the status of the service is the characteristic "status.status" (is a text field)
+ - Then we go to _CR_CHECKVAL_AVAILABLE and we define the value CALCULATED, which signals the following: When the characteristic "status.status" has the value "CALCULATED" then OpenSlice will mark the underlying service as "ACTIVE"
+ - We need also to define the yaml file that OpenSLice will use to create the new resource in the kubernetes cluster
+ - We insert the YAML in the characteristic _CR_SPEC
+
+ the _CR_SPEC is: ```
+apiVersion: examples.osl.etsi.org/v1alpha1
+kind: MyCalculator
+metadata:
+ name: mycalculator.examples.osl.etsi.org
+spec:
+ parama: 170
+ paramb: 180
+ action: 'SUM'
+
+```
+
+<img src="img11.png" width=1024px>
+
+
+> However the values are fixed. How do we allow a user to pass parameters through OpenSlice
+
+### Pass parameters through OpenSlice
+
+We need to Create LCM rules in ResourceFacingServiceSpecification
+- The goal of the rules is to allow the user to pass parameters to the actual resource towards the cluster.
+- we will create one rule that will pass the parameters just before creating the service (PRE_PROVISION phase)
+- we will create one rule that will pass the parameters while the service is active (SUPERVISION phase)
+- The rules will be the same
+
+<img src="img12.png" width=1024px>
+
+If we see one rule it will look like the following:
+<img src="img13.png" width=1024px>
+
+- We need to change the _CR_SPEC characteristic
+- We use a block that changes a String according to variables
+- See that we have as Input string the YAML string lines
+ - see that parama, paramb has a %d (they accept integers), action is %s (accepts a string)
+ - See that the variables tha will replace the %d, %d and %s are an list
+ - the first %d will be replaced with the value from characteristic spec.parama
+ - the second %d will be replaced with the value from characteristic spec.paramb
+ - the %s will be replaced with the value from characteristic spec.action
+
+
+
+### Create a CustomerFacingServiceSpecification
+
+We will now expose it to our users by creating a CustomerFacingServiceSpecification
+
+<img src="img14.png" width=1024px>
+
+Expose it then to a catalogue for orders through the Service Categories and Service Catalogs
+
+
+<img src="img15.png">
+
+
+### Order the Service
+
+When a user orders the service, it will look like this:
+
+<img src="img16.png" width=1024px>
+
+
+
+- After the Service Order we have 2 services in service inventory on CFS and on RFS. Both have references to values
+- CRIDGE updates the Resource in Resource Inventory and OSOM updated the Services in Service Inventory
+- The Actual resources are running in the Kubernetes cluster managed by OpenSlice
+- The result is in the characteristic status.result
+
+<img src="img17.png" width=800px>
+
+<img src="img18.png" width=1024px>
+
+ ### Modify the running service
+
+ The use can modify the service
+
+<img src="img19.png" width=1024px>
+
+- After a while the update is applied to the cluster, the controller will pick up the resource update and patch the resource
+- CRIDGE updates the Resource in Resource Inventory and OSOM updates the Services in Service Inventory
+
+
+<img src="img20.png" width=1024px>
+
\ No newline at end of file
diff --git a/docs/img11.png b/docs/ExposingCRDs_aaS_Example_Calculator/img11.png
similarity index 100%
rename from docs/img11.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img11.png
diff --git a/docs/img12.png b/docs/ExposingCRDs_aaS_Example_Calculator/img12.png
similarity index 100%
rename from docs/img12.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img12.png
diff --git a/docs/img13.png b/docs/ExposingCRDs_aaS_Example_Calculator/img13.png
similarity index 100%
rename from docs/img13.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img13.png
diff --git a/docs/img14.png b/docs/ExposingCRDs_aaS_Example_Calculator/img14.png
similarity index 100%
rename from docs/img14.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img14.png
diff --git a/docs/img15.png b/docs/ExposingCRDs_aaS_Example_Calculator/img15.png
similarity index 100%
rename from docs/img15.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img15.png
diff --git a/docs/img16.png b/docs/ExposingCRDs_aaS_Example_Calculator/img16.png
similarity index 100%
rename from docs/img16.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img16.png
diff --git a/docs/img17.png b/docs/ExposingCRDs_aaS_Example_Calculator/img17.png
similarity index 100%
rename from docs/img17.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img17.png
diff --git a/docs/img18.png b/docs/ExposingCRDs_aaS_Example_Calculator/img18.png
similarity index 100%
rename from docs/img18.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img18.png
diff --git a/docs/img19.png b/docs/ExposingCRDs_aaS_Example_Calculator/img19.png
similarity index 100%
rename from docs/img19.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img19.png
diff --git a/docs/img20.png b/docs/ExposingCRDs_aaS_Example_Calculator/img20.png
similarity index 100%
rename from docs/img20.png
rename to docs/ExposingCRDs_aaS_Example_Calculator/img20.png
diff --git a/docs/ExposingKubernetesResources.md b/docs/ExposingKubernetesResources.md
new file mode 100644
index 0000000000000000000000000000000000000000..a4a0208cc84bb22f2719507848e402d034fe3312
--- /dev/null
+++ b/docs/ExposingKubernetesResources.md
@@ -0,0 +1,159 @@
+
+# Expose and manage Kubernetes Custom Resource Definitions (Operators) in a Kubernetes Cluster
+
+OpenSlice is capable of exposing Kubernetes Resources and Definitions as Service Specifications
+
+## Intended Audience: Service Designers
+
+ > Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box. Custom Resource Definitions (CRDs) is a way that allows to manage things other than Kubernetes itself and allows to create our own objects The use of CRDs makes the possibilities of Kubernetes management almost limitless. You can extend the base Kubernetes API with any object you like using CRDs.
+
+ > By allowing the design and lifecycle management of services/resources that expose CRDs/CRs in a Kubernetes cluster via the TMF APIs, OSL can be used in many complex scenarios now involing resources from multiple domains.
+
+
+1. OpenSlice is capable to:
+ - Create and manage Custom Resources (CRs) using installed CRDs on a target Kubernetes cluster.
+ - Facilitate complex orchestration scenarios by wrapping Kubernetes APIs as TMF APIs and models.
+ - Handles connectivity to a Kubernetes cluster and manages the lifecycle of CRDs
+ - Wraps the Kubernetes API, Receives and provides resources towards other OpenSlice services via the service bus
+
+2. Enabling Loose Coupling and Orchestration
+ - Language Flexibility: Developers can write CRDs in any language and expose them via the Kubernetes APIs. OSL will reuse these CRDs, enhancing flexibility and integration capabilities.
+ - Familiar Deployment: Developers can create and deploy applications using familiar tools such as Helm charts, simplifying the process and reducing the learning curve.
+
+3. Ecosystem Reusability
+ - OpenSlice capitalizes on the extensive Kubernetes ecosystem, particularly focusing on operators (CRDs).
+ - Key repositories and hubs such as artifacthub.io and Operatorhub.io can be utilized for finding and deploying operators.
+
+4. Service Catalog Exposure and Deployment
+ - OpenSlice can expose CRs in service catalogs, facilitating their deployment in complex scenarios.
+ - These scenarios may include service bundles that involve multiple systems, such as RAN controllers or other Kubernetes clusters, providing a robust and versatile deployment framework.
+
+# Approach
+
+ > OpenSlice in general is responible for exposing service specifications which are ready to be ordered and orchestrated, through tmforum Open APIs as defined in the OSL Service Spec Catalog. Usually for a service specification a corresponding (one or more) resource specification (resourceSpecificationReference) is registered in the OSL Resource Spec Catalog.
+
+The following image illustrates the approach.
+
+<img src="img01.png" width=1024px>
+
+1. A CRD in a cluster will be mapped in TMF model as a Resource specification and therefore can be exposed as a service specification in a catalog
+2. Service Orders can be created for this service specification.
+3. OSOM creates a Resource in OSL Resource inventory and requests new Custom Resource (CR) in the target cluster
+ - The resource is created in a specific namespace (for example the UUID of the Service Order)
+ - A CR in a cluster will be mapped in TMF model as a Resource in the resource Inventory
+ - Other related resources created by the CRD Controller within the namespace are automatically created in OSL Resource Inventory under the same Service Order
+
+
+# Awareness for CRDs and CRs in cluster
+
+> CRDs and CRs can appear (disappear) or change status at any time in a cluster. OpenSlice Resource Inventory need to be aware of these events.
+
+ When installing OpenSlice you can configure at least one management cluster. OpenSlice connects via a provided kubeconf
+
+- On Start up OSL tries to register this cluster and context to OSL catalogs.
+- After the registration of this cluster as a Resource in OSL OSL is always aware of all CRDs and their CRs in the cluster, even if a CRD or CR is added/updated/deleted in the K8S cluster outside of OSL
+- Resources created by OpenSlice have labels, e.g. (org.etsi.osl.*)
+
+# Expose CRDs as Service Specifications in OpenSlice catalogs
+
+**A CRD by default is exposed as a Resource Specification**
+
+All attributes of the CRD are translated into characteristics
+
+The following specific characteristics are **added**:
+
+ - _CR_SPEC: Used for providing the json Custom Resource description to apply
+ - _CR_CHECK_FIELD: Used for providing the field that need to be checked for the resource status
+ - _CR_CHECKVAL_STANDBY: Used for providing the equivalent value from resource to signal the standby status
+ - _CR_CHECKVAL_ALARM: Used for providing the equivalent value from resource to signal the alarm status
+ - _CR_CHECKVAL_AVAILABLE: Used for providing the equivalent value from resource to signal the available status
+ - _CR_CHECKVAL_RESERVED: Used for providing the equivalent value from resource to signal the reserved status
+ - _CR_CHECKVAL_UNKNOWN: Used for providing the equivalent value from resource to signal the unknown status
+ - _CR_CHECKVAL_SUSPENDED: Used for providing the equivalent value from resource to signal the suspended status
+
+
+1. Create a new Service Specification and use this Resource Specification in Resource Specification Relationships
+ - Then the Service Specification is saved as ResourceFacingServiceSpecification
+
+ 1.1. You can give at this stage values to the characteristics:
+
+ - _CR_SPEC,
+ - _CR_CHECK_FIELD
+ - _CR_CHECKVAL_STANDBY
+ - _CR_CHECKVAL_ALARM
+ - _CR_CHECKVAL_AVAILABLE
+ - _CR_CHECKVAL_RESERVED
+ - _CR_CHECKVAL_UNKNOWN
+ - _CR_CHECKVAL_SUSPENDED
+
+ 1.2. You can now create LCM rules if you wish
+
+2. Create a new Service Specification and use the Resource Facing Service Specification in Service Specification Relationships
+ - Then the Service Specification is saved as CustomerFacingServiceSpecification
+
+ 2.1. You can give at this stage values to the characteristics:
+
+ - _CR_SPEC,
+ - _CR_CHECK_FIELD
+ - _CR_CHECKVAL_STANDBY
+ - _CR_CHECKVAL_ALARM
+ - _CR_CHECKVAL_AVAILABLE
+ - _CR_CHECKVAL_RESERVED
+ - _CR_CHECKVAL_UNKNOWN
+ - _CR_CHECKVAL_SUSPENDED
+
+ 2.2. You We can create LCM rules for this new Service Specification
+
+ 2.3. You Expose configurable values for users to configure during service order
+
+<img src="img06.png" width=1024px>
+
+
+# Service Orchestration and CRDs/CRs
+
+OSOM - OpenSlice Service Orchestrator, checks the presence of attribute _CR_SPEC at the RFS to make a request for a CR deployment
+
+- _CR_SPEC is a JSON or YAML string that is used for the request
+ - It is similar to what one will do with e.g. a kubectl apply
+ - There are tools to translate a yaml file to a json
+
+> LCM rules can be used to change attributes of this yaml/json file, before sending this for orchestration
+
+
+## Mapping the CR lifecycle that is defined in the CRD with the OpenSLice (TMF-based) resource Lifecycle
+
+OpenSlice adds automatically as we see the following characteristics:
+
+ - _CR_CHECK_FIELD
+ - _CR_CHECKVAL_STANDBY
+ - _CR_CHECKVAL_ALARM
+ - _CR_CHECKVAL_AVAILABLE
+ - _CR_CHECKVAL_RESERVED
+ - _CR_CHECKVAL_UNKNOWN
+ - _CR_CHECKVAL_SUSPENDED
+
+**These characteristics instrument OpenSlice services to manage and reflect the lifecycle of a kubernetes resource to OpenSlice's (TMF based) lifecycle**
+
+
+- _CR_CHECK_FIELD: The name of the field that is needed to be monitored in order to monitor the status of the service and translate it to TMF resource statys (RESERVED AVAILABLE, etc)
+- _CR_CHECKVAL_STANDBY: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state STANDBY (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
+- _CR_CHECKVAL_ALARM: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state ALARMS (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
+- _CR_CHECKVAL_AVAILABLE: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state AVAILABLE (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
+- _CR_CHECKVAL_RESERVED: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state RESERVED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
+- _CR_CHECKVAL_UNKNOWN: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state UNKNOWN (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
+- _CR_CHECKVAL_SUSPENDED: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state SUSPENDED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
+
+
+---
+
+## What's next?
+
+
+ - See examples of exposing operators via OpenSlice:
+ - [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](ExposingCRDs_aaS_Example_Calculator.md)
+ - [Learn more about CRIDGE, the service in OSL that manages CRDs/CRs](CRIDGEforDevelopers_Jenkins_Example.md)
+
+
+
+
+
diff --git a/docs/HELM_Installation_aaS_Jenkins_Example/HELM_Installation_aaS_Jenkins_Example.md b/docs/HELM_Installation_aaS_Jenkins_Example/HELM_Installation_aaS_Jenkins_Example.md
new file mode 100644
index 0000000000000000000000000000000000000000..6309c55a0bbdda7ba98929944fc0b2afeb51882b
--- /dev/null
+++ b/docs/HELM_Installation_aaS_Jenkins_Example/HELM_Installation_aaS_Jenkins_Example.md
@@ -0,0 +1,17 @@
+# Expose HELM charts as Service Specifications
+Manage Helm charts installations via OpenSlice Service Specifications and Service Orders.
+## Intended Audience: Service Designers
+
+
+> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box.
+> Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package
+> At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests -- and a given chart can have child charts and dependent charts, as well. Using Helm charts:
+> - Reduces the complexity of deploying Microservices
+> - Enhances deployment speed
+> - Developers already know the technology
+> There are many Helm charts and Helm repositories there that are ready to be used
+
+
+
+
+