- NONRTRIC-944Getting issue details... STATUS
Gerrit https://gerrit.o-ran-sc.org/r/nonrtric/plt/sme
Service Manager builds on CAPIF and depends on the Kong API Gateway. CAPIF stands for common API framework and it was developed by 3GPP to enable a unified Northbound API framework across 3GPP network functions, and to ensure that there is a single and harmonized approach for API development. Among CAPIF's key features are the following.
- Register/deregister APIs
- Publishing APIs
- Onboarding/offboarding API invoker
- Discovery APIs
- CAPIF events subscription/notification
- Entity authentication/authorization
- Support for 3rd party domains i.e., allow 3rd party API providers to leverage the CAPIF framework
- Support interconnection between two CAPIF providers
CAPIF implements 3GPP TS 29.222 V17.5.0 Common API Framework for 3GPP Northbound APIs. Service Manager also implements 3GPP TS 29.222 V17.5.0 Common API Framework for 3GPP Northbound APIs. Service Manager uses a subset of CAPIF to provide the following APIs.
- Register/deregister APIs
- Publishing APIs
- Onboarding/offboarding API invoker
- Discovery APIs
If you only need the above APIs, then Service Manager is a plugin-in replacement for CAPIF.
CAPIF core function APIs implemented by Service Manager
The table below lists the CAPIF Core Function APIs that are currently implemented in Service Manager. The Service Names are listed in the order that they would typically be called.
Service Name | Service Operations | Operation Semantics | Consumer(s) |
CAPIF_API_Provider_Management_API | Register_API_Provider | POST /registrations | API Management Function |
Update_API_Provider | PUT /registrations/{registrationId} | API Management Function | |
Deregister_API_Provider | DELETE /registrations/{registrationId} | API Management Function | |
CAPIF_Publish_Service_API | Publish_Service_API | POST /{apfId}//service-apis | API Publishing Function, CAPIF core function |
Unpublish_Service_API | DELETE /{apfId/service-apis/{serviceApiId} | API Publishing Function, CAPIF core function | |
Update_Service_API | PUT /{apfId/service-apis/{serviceApiId} | API Publishing Function, CAPIF core function | |
Get_Service_API | GET /{apfId}/service-apis | API Publishing Function, CAPIF core function | |
CAPIF_API_Invoker_Management_API | Onboard_API_Invoker | POST /onboardedInvokers | API Invoker |
Offboard_API_Invoker | DELETE /onboardedInvokers/{onboardingId} | API Invoker | |
Update_API_Invoker_Details | PUT /onboardedInvokers/{onboardingId} | API Invoker | |
CAPIF_Discover_Service_API | Discover_Service_API | GET /allServiceAPIs | API Invoker, CAPIF core function |
Service Manager integration with Kong
When you call the Publish Service API of Service Manager, the requests body contains the IPv4 address and port of the API Publishing Function. In the response body, these values are replaced by the IP v4 Address and port of the Kong Data Plane. This allows us to use Kong as a reverse proxy. Instead of calling the Publishing service directly, our Invoker's API request is proxied through Kong. This gives us the advantages of using a proxied service, such as providing caching and load balancing.
Service Manager Deployment
Stand-alone Deployment on Kubernetes
For a stand-alone development deployment, please see the `deploy` folder for configurations to deploy Service Manager to Kubernetes. We need the following steps.
- Deploy a PV for Kong's Postgres database (depends on your Kubernetes cluster)
- Deploy a PVC for Kong's Postgres database
- Deploy Kong with Postgres
- 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.
- sme/
- servicemanager/
- deploy/
- src/
- manifests/
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 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.
`./deploy-to-k8s.sh --repo your-docker-repo-id --env ../../.env.minikube`
When Service Manager starts, it reads a .env file where you can configure information such as the Kong control and data planes' host and port, the CAPIF host and port, and the Service Manager port.
Sample .env
KONG_DOMAIN=<string> KONG_PROTOCOL=<http or https protocol scheme> KONG_IPV4=<host string> KONG_DATA_PLANE_PORT=<port number> KONG_CONTROL_PLANE_PORT=<port number> CAPIF_PROTOCOL=<http or https protocol scheme> CAPIF_IPV4=<host> CAPIF_PORT=<port number> LOG_LEVEL=<Trace, Debug, Info, Warning, Error, Fatal or Panic> SERVICE_MANAGER_PORT=<port number> TEST_SERVICE_IPV4=<host string> TEST_SERVICE_PORT=<port number>