X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=blobdiff_plain;f=capifcore%2FREADME.md;h=1f70c6ed69eaafb0b2d2d7be236f2709fbce178b;hb=b4cee94bd251b0bb92fc435fbe74ea1079d43356;hp=657687fda7951d7ebaecf8537f2aa7a4527151a8;hpb=c2422dba52b7c2fe640ff957137ccf64d2c96753;p=nonrtric%2Fplt%2Fsme.git diff --git a/capifcore/README.md b/capifcore/README.md index 657687f..1f70c6e 100644 --- a/capifcore/README.md +++ b/capifcore/README.md @@ -20,14 +20,33 @@ --> -# O-RAN-SC Non-RealTime CAPIF implementation +# O-RAN-SC Non-RealTime RIC CAPIF Core implementation -This product is a Go implementation of the CAPIF Core function, based on the 3GPP CAPIF interfaces. +This product is a Go implementation of the CAPIF Core function, based on the 3GPP "29.222 Common API Framework for 3GPP Northbound APIs (CAPIF)" interfaces, see https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3450. + +The, almost, complete data model for CAPIF is shown in the diagram below. + + + +The data used within CAPIF Core for registering rApps that both provides and consumes services is shown in the diagram below. + + + +Some examples of interactions between components using the CAPIF interface are shown in the sequence diagram below. + +***NOTE!*** It has not been decided that CAPIF Core will actually do the Helm chart installation. This is just provided in the prototype as an example of what CAPIF Core could do. + + + +If Helm is used, before publishing a service, the chart that belongs to the service must be registered in ChartMuseum. When publishing the service the following information should be provided in the `ServiceAPIDescription::description` attribute; "namespace", "repoName", "chartName", "releaseName". An example of the information: "Description of rApp helloWorld,namespace,repoName,chartName,releaseName". ## Generation of API code -The CAPIF APIs are generated from the OpenAPI specification provided by 3GPP. The `generate.sh` script downloads the -specifications from 3GPP, fixes them and then generates the APIs. It also generates the mocks needed for unit testing. 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 CAPIF APIs are generated from the OpenAPI specifications provided by 3GPP. The `generate.sh` script downloads the +specifications from 3GPP, fixes them and then generates the APIs. It also generates the mocks needed for unit testing. +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. To fix the specifications there are three tools: - `commoncollector`, collects type definitions from peripheral specifications to keep down the number of dependencies to @@ -35,12 +54,30 @@ To fix the specifications there are three tools: - `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. +### Steps to add a new dependency to the commoncollector + +When a dependency to a new specification is introduced in any of the CAPIF specifications, see example below, the following steps should be performed: + +For the CAPIF specification "TS29222_CAPIF_Discover_Service_API" a new dependency like the following has been introduced. + + websockNotifConfig: + $ref: ✅TS29122_CommonData.yaml#/components/schemas/WebsockNotifConfig✅' + +1. Copy the part between the checkboxes of the reference and add it to the `definitions.txt` file. This step is not needed if the type is already defined in the file. +2. Look in the `generate.sh` script, between the "" and "" tags, to see if "TS29122_CommonData" + has already been replaced in "TS29222_CAPIF_Discover_Service_API". +3. If it has not been replaced, add a replacement above the "" tag by copying and adapting the two rows above the tag. + ## Build and test To generate mocks manually, run the following command: go generate ./... +**NOTE!** The `helmmanagement` package contains two mocks from the `helm.sh/helm/v3` product. If they need to be +regenerated, their interfaces must be copied into the `helm.go` file and a generation annotation added before running +the generation script. + To build the application, run the following command: go build @@ -55,7 +92,8 @@ The application can also be built as a Docker image, by using the following comm ## Run -To run the Core Function from the command line, run the following commands from this folder. +To run the Core Function from the command line, run the following commands from this folder. For the parameter `chartMuseumUrl`, if it is not provided CAPIF Core will not do any Helm integration, i.e. try to start any Halm chart when publishing a service. - ./capifcore [-port ] + ./capifcore [-port ] [-secPort ] [-chartMuseumUrl ] [-repoName ] [-loglevel ] [-certPath ] [-keyPath ] +To run CAPIF Core as a K8s pod together with ChartMuseum, start and stop scripts are provided. The pod configurations are provided in the `configs` folder. CAPIF Core is then available on port `31570`.