```
The specifications are downloaded from the following site; https://www.3gpp.org/ftp/Specs/archive/29_series. To see
-the APIs in swagger format, see the following link; https://github.com/jdegre/5GC_APIs/tree/Rel-16#common-api-framework-capif.
-**NOTE!** The documentation in this link is for release 16 of CAPIF, the downloaded specifications are for release 17.
+the APIs in swagger format, see the following link; https://github.com/jdegre/5GC_APIs/tree/Rel-17#common-api-framework-capif.
To fix the specifications there are three tools.
- `commoncollector`, collects type definitions from peripheral specifications to keep down the number of dependencies to
- other specifications. The types to collect are listed in the `definitions.txt`file. Some fixes are hard coded.
+ other specifications. The types to collect are listed in the `definitions.txt` file. Some fixes are hard-coded.
- `enumfixer`, fixes enumeration definitions so they can be properly generated.
-- `specificationfixer`, fixes flaws in the specifications so they can be properly generated. All fixes are hard coded.
+- `specificationfixer`, fixes flaws in the specifications so they can be properly generated. All fixes are hard-coded.
## Set Up
First, we need to run `generate.sh` as described above to generate our API code from the 3GPP spec.
-Before we can test or run R1-SME-Manager, we need to configure a .env file with the required parameters. Please see the template .env.example in the servicemanager directory.
+Before we can test or run Service Manager, we need to configure a .env file with the required parameters. Please see the template .env.example in the servicemanager directory.
You can set the environmental variable SERVICE_MANAGER_ENV to specify the .env file. For example, the following command specifies to use the config file
.env.development. If this flag is not set, first we try .env.development and then .env.
export SERVICE_MANAGER_ENV=development
```
-### Capifcore and Kong
+### CAPIFcore and Kong
-We also need Kong and Capifcore to be running. Please see the examples in the `configs` folder.
+We also need Kong and CAPIFcore to be running. Please see the examples in the `deploy` folder. You can also use https://gerrit.o-ran-sc.org/r/it/dep for deployment. Please see the notes at https://wiki.o-ran-sc.org/display/RICNR/%5BWIP%5D+Service+Manager.
## Build
## Unit Tests
-To run the unit tests for the application, first ensure that the .env file is configured. In the following example, we specify `.env.test`. For now, we need to disable parallelism in the unit tests with -p=1.
+To run the unit tests for the application, first ensure that the .env file is configured. In the following example, we specify `.env.test`.
```sh
export SERVICE_MANAGER_ENV=test
-go test -p=1 -count=1 ./...
+go test ./...
```
## Run Locally
./servicemanager
```
-R1-SME-Manager is then available on the port configured in .env.
+Service Manager is then available on the port configured in .env.
## Building the Docker Image
-The application can also be built as a Docker image, by using the following command. We build the image without a .env file. This is supplied by volume mounting at container run-time. Because we need to include Capifcore in the Docker build context, we build from the git repo's root directory, sme.
+The application can also be built as a Docker image, by using the following command. We build the image without a .env file. This is supplied by volume mounting at container run-time. Because we need to include CAPIFcore in the Docker build context, we build from the git repo's root directory, sme.
```sh
docker build -t servicemanager -f servicemanager/Dockerfile .
## Kongclearup
-Please note that a special executable has been provided for deleting Kong routes and services that have been created ServiceManager in Kong. This executable is called `kongclearup` and is found in the working directory of the ServiceManger Docker image, at `/app/kongclearup`. When we create a Kong route or service, we add Kong tags with information as follows.
+Please note that a special executable has been provided for deleting Kong routes and services that have been created by Service Manager in Kong. This executable is called `kongclearup` and is found in the working directory of the Service Manger Docker image, at `/app/servicemanager`. When we create a Kong route or service, we add Kong tags with information as follows.
* apfId
* aefId
* apiId
* apiVersion
* resourceName
-When we delete Kong routes and services using `kongclearup`, we check for the existance of these tags, specifically, apfId, apiId and aefId. Only if these tags exist and have values do we proceed to delete the Kong service or route.
-
-The executable `kongclearup` uses the volume-mounted .env file to load the configuration giving the location of Kong.
-
-Please refer to `sme/servicemanager/internal/kongclearup.go`.
+When we delete Kong routes and services using `kongclearup`, we check for the existance of these tags, specifically, apfId, apiId and aefId. Only if these tags exist and have values do we proceed to delete the Kong service or route. The executable `kongclearup` uses the volume-mounted .env file to load the configuration giving the location of Kong. Please refer to `sme/servicemanager/internal/kongclearup.go`.
## Stand-alone Deployment on Kubernetes
-For a stand-alone deployment, please see the `deploy` folder for configurations to deploy to R1-SME-Manager to Kubernetes. We need the following steps.
- - Deploy a PV for Kong's Postgres database (depends on your Kubernetes cluster)
+For a stand-alone deployment, please see the `deploy` folder for configurations to deploy to Service Manager to Kubernetes. We need the following steps.
+ - Deploy a PV for Kong's Postgres database (depends on your Kubernetes cluster, not needed for Minikube)
- Deploy a PVC for Kong's Postgres database
- Deploy Kong with Postgres
- - Deploy Capifcore
- - Deploy R1-SME-Manager
+ - Deploy CAPIFcore
+ - Deploy Service Manager
We consolidate the above steps into the script `deploy-to-k8s.sh`. To delete the full deployment, you can use `delete-from-k8s.sh`. The deploy folder has the following structure.
We store the Kubernetes manifests files in the manifests in the subfolder. We store the shell scripts in the src folder.
-In `deploy-to-k8s.sh`, we copy .env.example and use sed to replace the template values with values for testing/production. You will need to update this part of the script with your own values. There is an example sed replacement in function `substitute_manifest()` in `deploy-to-k8s.sh`. Here, you can substitute your own Docker images for Capifcore and Service Manager for local development.
+In `deploy-to-k8s.sh`, we copy .env.example and use `sed` to replace the template values with values for running the Service Manager container. You will need to update this part of the script with your own values. There is an example sed replacement in function `substitute_manifest()` in `deploy-to-k8s.sh`. Here, you can substitute your own Docker images for CAPIFcore and Service Manager for local development.
In addition there are 2 switches that are added for developer convenience.
- * --repo # allow you to specify your own docker repo
- * --env # allow you to specify an additional env file, and set SERVICE_MANAGER_ENV to point to this file.
+ * --repo # allows you to specify your own docker repo, e.g. your Docker Hub id
+ * --env # allows you to specify an additional env file, and sets SERVICE_MANAGER_ENV in the Docker environment to point to this file.
+
+The additional env file needs to exist in the sme/servicemanager folder so that kongclearup can access is. It is specified by its filename. The relative path ../.. is added in the `deploy-to-k8s.sh` script. For example, to use
+
+`./deploy-to-k8s.sh --env .env.development`
-`./deploy-to-k8s.sh --repo your-docker-repo-id --env ../../.env.minikube`
+ ../../.env.development needs to exist.
\ No newline at end of file
Code Review / nonrtric / plt / sme.git / blobdiff