From fb0f7a23b295120fa8147f513778d8fb9b700fc7 Mon Sep 17 00:00:00 2001
From: Eduardo Santos <eduardosantoshf@gmail.com>
Date: Tue, 28 Jan 2025 15:23:45 +0000
Subject: [PATCH 1/2] Minot fixes on the documentation
---
QoDProvisioning/README.md | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/QoDProvisioning/README.md b/QoDProvisioning/README.md
index 822abe7..0b395f2 100644
--- a/QoDProvisioning/README.md
+++ b/QoDProvisioning/README.md
@@ -136,7 +136,7 @@ Regarding the RFS Service, you must set the following characteristics:
By setting these characteristics, you will rely on the value of `spec.status` to set the service as `active`. Ideally, the 5G Core provider would have implemented a proper Kubernetes Operator for this Custom Resource to implement the requested QoD. However, as discussed already, for demonstration purposes, we will short-circuit the behavior and we will set `spec.status` to `RUNNING` immediately after deployment.
-Then, you can proceed to create a Customer-Facing-Service (CFS) Specification, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/). To create the CFS Service's characteristics, you may use the Service Specification available at `/DummyOperatorService/OSLArtifacts/DummyOperatorService-CFS-Specification.json` . You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to *[{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification](https://www.notion.so/CAMARAaaS-OSL-15e11fa2ed8d80808254c87d9393cf51?pvs=21).*
+Then, you can proceed to create a Customer-Facing-Service (CFS) Specification, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/). To create the CFS Service's characteristics, you may use the Service Specification available at `/DummyOperatorService/OSLArtifacts/DummyOperatorService-CFS-Specification.json` . You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to `{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification`.
After creating the CFS Specification, you should mark this Service as a Bundle. Then, go to “Service Specification Relationships†and add the previous created RFS Specification.
@@ -211,29 +211,25 @@ After that, you may expose this service via OSL’s Service Catalog, and order i
### 2. OSL CAMARAaaS QoD Provisioning API exposure Service Design
-Then, we can proceed to design the CAMARAaaS QoD Provisioning API exposure Service Specification in OSL catalogue. To this end, OSL’s team has implemented in Python the CAMARAaaS QoD Provisioning API, created a CRD to offer it, and developed a Kubernetes Operator to deal with its internal logic. Start by packaging the API in a docker image and pushing it to a docker repository.
-
-Open the file `Makefile` and update the repository to where you will push the docker image. Update the variable `REPOSITORY_HOST`. You may also choose to update the other variables, but it is not required. After this, run `make api-docker-image`. This command will build, tag, and push the API docker image to the repository you chose.
+Then, we can proceed to design the CAMARAaaS QoD Provisioning API exposure Service Specification in OSL catalogue. To this end, OSL’s team has implemented in Python the CAMARAaaS QoD Provisioning API, created a CRD to offer it, and developed a Kubernetes Operator to deal with its internal logic.
#### 2.1 OSL CAMARAaaS QoD Provisioning API - Kubernetes Operator
-The previous docker image shall make available the CAMARA QoD Provisioning API. However, these API will be made available through Custom Resources of Type `CAMARAaaS-QoDProvisiongAPI`. Therefore, we also need a Kubernetes Operator to manage these resources. The Operator’s code can be found under `/QoDProvisioningAPI/Operator`. There, you have the source code of the Kubernetes Operator, as well as an Helm Chart to install it.
-
-Start by building and pushing the Kubernetes Operator’s docker image to your repository. Run `make operator-docker-image`. Then, install the operator in your Kubernetes cluster. This action will result in the creation of the CRD for the CAMARA QoD Provisioning API Resources, and deploy the operator in the cluster. It is this operator that will manage the CAMARA QoD Provisioning API Resources, being responsible, for instance, for the deployment a Kubernetes pod and service that expose the CAMARA QoD Provisioning API. To install the Operator, run the following command:
+The previous docker image shall make available the CAMARA QoD Provisioning API. However, these API will be made available through Custom Resources of Type `CAMARAaaS-QoDProvisiongAPI`. Therefore, we also need a Kubernetes Operator to manage these resources. The Operator’s code can be found under `/QoDProvisioningAPI/Operator`. There, you have the source code of the Kubernetes Operator. The Operator's Helm Chart uses the default OSL registry docker images. If you are interesting in developing your own, please refer to the Makefile. To install the Operator, run the following command:
```bash
-helm install camaraaas-qod-prov-operator ./QoDProvisioningAPI/Operator/chart --set operator.image=<your_operator_image> --set camaraQoDAPI.image=<your_api_image> --namespace <namespace_where_the_operator_shall_be_deployed> --create-namespace
+helm install camaraaas-qod-prov-operator ./QoDProvisioningAPI/Operator/chart --namespace <namespace_where_the_operator_shall_be_deployed> --create-namespace
```
-To simplify things, you may also run: `make install-operator`. After this, check if the operator is running through the `make get-operator-logs` command.
+After this, check if the operator is running through the `make get-operator-logs` command.
-If everything went ok, you should have a new CRD in your Kubernetes cluster. Run this command to verify if it was created: `kubectl describe crd camaraaas-qod-provisioning-apis.org.etsi.osl`.
+If everything went ok, you should have a new CRD in your Kubernetes cluster. Run this command to verify if it was created: `kubectl describe crd camaraaas-qod-provisioning-apis.org.etsi.osl`.
Before designing the service in OSL, let us first create a CR of type `CAMARAaaS-QoDProvisiongAPI` to validate that the operator is behaving according to what is expected. To this end, you may use the test custom resource available at `/QoDProvisioningAPI/Operator/test-cr.yaml` . Before creating the resource, you need to update the fields: *spec.messageBroker.address*, *spec.messageBroker.port, spec.messageBroker.username, spec.messageBroker.password*, with the values that relate with your OSL instance. The default values will be the following ones:
- *spec.messageBroker.address: <your OSL address>*
-- s*pec.messageBroker.port*: 61613
+- *pec.messageBroker.port*: 61613
- *spec.messageBroker.username: artemis*
- *spec.messageBroker.password: artemis*
@@ -260,7 +256,7 @@ Regarding the RFS Service, you must set the following characteristics:
By setting this characteristics, you will rely on the value of `spec.camaraAPI.status` to set the service as `active`. The previous operator, when it deploys the CAMARA QoD Provisioning API will set that CR field to `RUNNING`.
-Then, you can proceed to create a CFS Service, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/). To create the CFS Service characteristics, you may use the Service Specification available at `/QoDProvisioningAPI/OSLArtifacts/CAMARAaaS-QoD-Provisioning-API-CFS-Specification.json`. You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to *[{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification](https://www.notion.so/CAMARAaaS-OSL-15e11fa2ed8d80808254c87d9393cf51?pvs=21).*
+Then, you can proceed to create a CFS Service, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](https://osl.etsi.org/documentation/latest/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator/). To create the CFS Service characteristics, you may use the Service Specification available at `/QoDProvisioningAPI/OSLArtifacts/CAMARAaaS-QoD-Provisioning-API-CFS-Specification.json`. You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to `{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification`.
After creating the Service Specification, you should mark this Service as a Bundle. Then, go to “Service Specification Relationships†and add the RFS Service.
--
GitLab
From 4048f903cadb3550da6c49a9d62875775e9d298b Mon Sep 17 00:00:00 2001
From: trantzas <ktrantzas@ece.upatras.gr>
Date: Fri, 31 Jan 2025 09:55:04 +0000
Subject: [PATCH 2/2] fix typos
---
QoDProvisioning/README.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/QoDProvisioning/README.md b/QoDProvisioning/README.md
index 0b395f2..e7e162c 100644
--- a/QoDProvisioning/README.md
+++ b/QoDProvisioning/README.md
@@ -228,10 +228,10 @@ If everything went ok, you should have a new CRD in your Kubernetes cluster. Run
Before designing the service in OSL, let us first create a CR of type `CAMARAaaS-QoDProvisiongAPI` to validate that the operator is behaving according to what is expected. To this end, you may use the test custom resource available at `/QoDProvisioningAPI/Operator/test-cr.yaml` . Before creating the resource, you need to update the fields: *spec.messageBroker.address*, *spec.messageBroker.port, spec.messageBroker.username, spec.messageBroker.password*, with the values that relate with your OSL instance. The default values will be the following ones:
-- *spec.messageBroker.address: <your OSL address>*
-- *pec.messageBroker.port*: 61613
-- *spec.messageBroker.username: artemis*
-- *spec.messageBroker.password: artemis*
+- *spec.messageBroker.address:* <your OSL address>
+- *spec.messageBroker.port*: 61613
+- *spec.messageBroker.username*: artemis
+- *spec.messageBroker.password*: artemis
For now, you do not need to update the field serviceUnderControl.uuid. You may leave it as is.
--
GitLab