Adding OpenAPI v3 specification for ORAN O2-ims provisioning v1.1

[andersheric]

Adding OpenAPI v3 specification for ORAN O2-ims provisioning v1.1 tracking O-RAN.WG6.TS.O2IMS-INTERFACE-R004-v10.00 protocol version 1.1.

I opted to create a new folder structure for OpenAPI specifications to not mix them with CRs and CDRs used for configuration adding confusion. My rationale is as follows:

/openapi - the openapi category of api specifications
/openapi/references - these are reference files, used as base for implementation, implementations add parallel folders, ex focom
/openapi/references/oran - for reference specifications these can track many sources , in this case ORAN apis
/openapi/references/oran/ims/provisioning - tracking the ORAN api structure, other ORAN apis could follow over time
/openapi/references/oran/ims/provisioning/o2ims_provisioning_v1_1.yaml the openapi specification tracking one specific version, as the api evolves new files will be added to track them

issue nephio-project/nephio#960

[nephio-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign efiacor for approval by writing /assign @efiacor in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: andersheric / name: Anders Henriksson (d883ae6, 2d44123, 43c2e7f, 03c15a4, a2c5f39, acda60a)

[nephio-prow]

Hi @andersheric. Thanks for your PR.

I'm waiting for a nephio-project member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[efiacor]

/ok-to-test

[efiacor]

I assume there is additional work to align the existing CRD with the new api spec?
https://github.com/nephio-project/api/blob/main/config/crd/bases/o2ims.provisioning.oran.org_provisioningrequests.yaml

[efiacor]

I am guessing this is a new "Phase" as it isn't in the current CRD.
https://github.com/nephio-project/api/blob/main/config/crd/bases/o2ims.provisioning.oran.org_provisioningrequests.yaml

[andersheric]

yes, new to the CRD but not new to the ORAN defined API. I think this was added already in v1 of the api in March this year. The current CRD implementation in Nephio is a pre O2-ims 1.0 implementation and does not fully align to the ORAN specification, it was our best guess at the time. This contribution is based on the v1.1 of the API as defined by O-RAN.WG6.TS.O2IMS-INTERFACE-R004-v10.00, there will need to be updates to the CRDs when adopting v1.1.

[efiacor]

Do we have an issue/epic to collate the work items?

[andersheric]

I will ask if we created an issue for the focus operator yet, last time I asked we had not.

But maybe I should explain one thing, this API spec is intended as a base for the focom client API spec and the o-cloud service API spec, but I dont expect this instance to be directly used in the implementation but rather as a common reference. The focom client may need to adapt the openapi spec to adapt to multiple o-cloud implementations and the o-cloud service api spec may need additional content describing Nephio specific extensions.

The point of this API spec is to be a common base where the client and service ends add only additive content and this way maintain compatibility. This PR should in itself not require or trigger any implementation updates or testing, that comes with the updated focom client user story when updating to support O2-ims provisioning API v1.1, similar for the o-cloud service endpoint.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud