From ef7c93b76e70b9f20f765e88fc97a09f8c5c4ead Mon Sep 17 00:00:00 2001
From: Christos Tranoris <tranoris@ece.upatras.gr>
Date: Tue, 18 Jun 2024 17:37:20 +0300
Subject: [PATCH] Edit docs #2
---
docs/CRIDGEforDevelopers.md | 174 ------------------
.../ExposingCRDs_aaS_Example_Calculator.md | 4 +-
2 files changed, 2 insertions(+), 176 deletions(-)
diff --git a/docs/CRIDGEforDevelopers.md b/docs/CRIDGEforDevelopers.md
index ab4ce70..defea97 100644
--- a/docs/CRIDGEforDevelopers.md
+++ b/docs/CRIDGEforDevelopers.md
@@ -206,180 +206,6 @@ OSOM sends to CRIDGE a message with the following information:
- It monitors and tries to figure out and map the Status of the CR to the TMF Status according to the provided org.etsi.osl.statusCheck* labels
- 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.
-
----
-## 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:
-
-
-```
-
-> 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? **
- - For this We introduced the following characteristics: _CR_CHECK_FIELD, _CR_CHECKVAL_STANDBY, _CR_CHECKVAL_ALARM, _CR_CHECKVAL_AVAILABLE, _CR_CHECKVAL_RESERVED, _CR_CHECKVAL_UNKNOWN, _CR_CHECKVAL_SUSPENDED
-
-OSOM sends to CRIDGE a message with the following information:
-
-- currentContextCluster: current context of cluster
-- clusterMasterURL: current master url of the cluster
-- org.etsi.osl.serviceId: This is the related service id that the created resource has a reference
-- org.etsi.osl.resourceId: This is the related resource id that the created CR will wrap and reference.
-- org.etsi.osl.prefixName: we need to add a short prefix (default is cr) to various places. For example in K8s cannot start with a number
-- org.etsi.osl.serviceOrderId: the related service order id of this deployment request
-- org.etsi.osl.namespace: requested namespace name
-- org.etsi.osl.statusCheckFieldName: 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)
-- org.etsi.osl.statusCheckValueStandby: 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)
-- org.etsi.osl.statusCheckValueAlarm: 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)
-- org.etsi.osl.statusCheckValueAvailable: 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)
-- org.etsi.osl.statusCheckValueReserved: 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)
-- org.etsi.osl.statusCheckValueUnknown: 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)
-- org.etsi.osl.statusCheckValueSuspended: 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)
-
-- Parameters:
- - aService reference to the service that the resource and the CR belongs to
- - resourceCR reference the equivalent resource in TMF repo of the target CR. One to one mapping
- - orderId related service order ID
- - startDate start date of the deployment (not used currently)
- - endDate end date of the deployment (not used currently)
- - _CR_SPEC the spec that is sent to cridge (in json)
-- Returns:
- - a string response from cridge. It might return "OK" if everything is ok. "SEE OTHER" if there are multiple CRIDGEs then some other cridge will handle the request for the equivalent cluster. Any other response is handled as error
-
-
-- CRIDGE receives the message and creates according to the labels the necessary CR
-- It monitors the created resource(s) in namespace (see the Sequence Diagram in previous images)
-- It monitors and tries to figure out and map the Status of the CR to the TMF Status according to the provided org.etsi.osl.statusCheck* labels
-- It sends to the message bus the current resource for creation or update to the TMF service inventory
---
diff --git a/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md b/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
index ea45b9f..28d8099 100644
--- a/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
+++ b/docs/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
@@ -194,7 +194,7 @@ When a user orders the service, it will look like this:
- 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
+- OpenSlice (via CRIDGE service) updates the Resource in Resource Inventory and OSOM updates 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
@@ -209,7 +209,7 @@ When a user orders the service, it will look like this:
<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
+- OpenSlice (via CRIDGE service) updates the Resource in Resource Inventory and OSOM updates the Services in Service Inventory
<img src="img20.png" width=1024px>
--
GitLab