feat: Adds IMSI QoS endpoint replacing DNN QoS from PolicyControl

[Gmerold]

This PR implements latest update to the new NF configuration system.

To acknowledge the fact that subscribers using the same DNN can be served with different QoS, new endpoint is introduced. The /nfconfig/qos/{dnn}/{imsi} endpoint allows getting the QoS configuration for a given IMSI.

[Copilot]

Pull Request Overview

This PR adds an IMSI-specific QoS endpoint replacing DNN-level QoS in the NF configuration API.

• Introduces new /nfconfig/qos/{dnn}/{imsi} path and ImsiQos schema in the OpenAPI spec.
• Removes the old DnnQos model and related references in PolicyControl.
• Implements client-side Go support for the new endpoint in api_default.go.

Reviewed Changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 1 comment.

File	Description
nfConfigApi/webconsole-api.yaml	Added new QoS path with ImsiQos schema, removed DnnQos usage.
nfConfigApi/model_*.go	Added compile-time MappedNullable checks across models and dropped DnnQos refs.
nfConfigApi/model_imsi_qos.go	Introduced generated ImsiQos model with JSON marshalling and validation.
nfConfigApi/api_default.go	Implemented NfconfigQosDnnImsiGet client methods using the new endpoint.

Comments suppressed due to low confidence (2)

nfConfigApi/webconsole-api.yaml:116

• Add a pattern field to the imsi parameter schema to enforce the expected format, e.g. ^imsi-\\d{15,16}$.

          description: IMSI in format “imsi-” followed by 15 or 16 digits

nfConfigApi/api_default.go:422

• Add unit tests for the new NfconfigQosDnnImsiGet client method to cover success, not-found, and error scenarios.

type ApiNfconfigQosDnnImsiGetRequest struct {

[gab-arrobo]

Overall, it looks good. I added some minor comments.
BTW, if you need to create a release (i.e., tag), you need to modify the VERSION file

[Gmerold]

Overall, it looks good. I added some minor comments. BTW, if you need to create a release (i.e., tag), you need to modify the VERSION file

Hello @gab-arrobo,
While I agree with your comments, all of the code in question has been auto generated by the openapi-generator. If I start changing the generated code, it will cause conflicts/changes every time we run the generator. Then we'll have to manually inspect every file to see what was changed and why and potentially revert the change manually.

Alternatively (for the consts specifically) I could update the enums in the webconsole-api.yaml, i.e.

Direction:
      type: string
      enum:
        - DIRECTION-DOWNLINK
        - DIRECTION-UPLINK
        - DIRECTION-BIDIRECTIONAL
        - DIRECTION-UNSPECIFIED

What do you think about that?

[patriciareinoso]

Overall, it looks good. I added some minor comments. BTW, if you need to create a release (i.e., tag), you need to modify the VERSION file

Hello @gab-arrobo, While I agree with your comments, all of the code in question has been auto generated by the openapi-generator. If I start changing the generated code, it will cause conflicts/changes every time we run the generator. Then we'll have to manually inspect every file to see what was changed and why and potentially revert the change manually.

Alternatively (for the consts specifically) I could update the enums in the webconsole-api.yaml, i.e.

Direction:
      type: string
      enum:
        - DIRECTION-DOWNLINK
        - DIRECTION-UPLINK
        - DIRECTION-BIDIRECTIONAL
        - DIRECTION-UNSPECIFIED

What do you think about that?

I agree, we should not modify the generated code.
You proposal of updating the enums in the yaml file seems appropriate

[gab-arrobo]

Overall, it looks good. I added some minor comments. BTW, if you need to create a release (i.e., tag), you need to modify the VERSION file

Hello @gab-arrobo, While I agree with your comments, all of the code in question has been auto generated by the openapi-generator. If I start changing the generated code, it will cause conflicts/changes every time we run the generator. Then we'll have to manually inspect every file to see what was changed and why and potentially revert the change manually.
Alternatively (for the consts specifically) I could update the enums in the webconsole-api.yaml, i.e.

Direction:
      type: string
      enum:
        - DIRECTION-DOWNLINK
        - DIRECTION-UPLINK
        - DIRECTION-BIDIRECTIONAL
        - DIRECTION-UNSPECIFIED

What do you think about that?

I agree, we should not modify the generated code. You proposal of updating the enums in the yaml file seems appropriate

No need to manually do that. There is an option to append the struct name as a prefix to the enums. Let me get back to you when I am in front of my computer.

[Gmerold]

Overall, it looks good. I added some minor comments. BTW, if you need to create a release (i.e., tag), you need to modify the VERSION file

Hello @gab-arrobo, While I agree with your comments, all of the code in question has been auto generated by the openapi-generator. If I start changing the generated code, it will cause conflicts/changes every time we run the generator. Then we'll have to manually inspect every file to see what was changed and why and potentially revert the change manually.
Alternatively (for the consts specifically) I could update the enums in the webconsole-api.yaml, i.e.

Direction:
      type: string
      enum:
        - DIRECTION-DOWNLINK
        - DIRECTION-UPLINK
        - DIRECTION-BIDIRECTIONAL
        - DIRECTION-UNSPECIFIED

What do you think about that?

I agree, we should not modify the generated code. You proposal of updating the enums in the yaml file seems appropriate

No need to manually do that. There is an option to append the struct name as a prefix to the enums. Let me get back to you when I am in front of my computer.

Thanks for the hint @gab-arrobo
Found it. It's enumClassPrefix=true. I'll fix the command in the README and the code.

[gab-arrobo]

No need to manually do that. There is an option to append the struct name as a prefix to the enums. Let me get back to you when I am in front of my computer.

Thanks for the hint @gab-arrobo Found it. It's enumClassPrefix=true. I'll fix the command in the README and the code.

I think this should do the job:

npx openapi-generator-cli generate \
  -i ./webconsole-api.yaml \
  -g go \
  -o ./nfConfigApi \
  --additional-properties=packageName=nfConfigApi,validateRequired=true,enumClassPrefix=true

[gab-arrobo]

Please address issue with GHA

[gab-arrobo]

@Gmerold,
The changes look good to me. Only one quick question... did you try to re-generate the modesl/API using the latest changes (i.e., using templates (partial_header, api, README))?
BTW, you need to address the issue with the copyright/license header in the api.mustache template. If you cannot address in the file itself, you could create another file named api.mustache.license and add the copyright/license header there (similar to how it is done in the go.mod and go.mod.license files)

[Gmerold]

@Gmerold, The changes look good to me. Only one quick question... did you try to re-generate the modesl/API using the latest changes (i.e., using templates (partial_header, api, README))? BTW, you need to address the issue with the copyright/license header in the api.mustache template. If you cannot address in the file itself, you could create another file named api.mustache.license and add the copyright/license header there (similar to how it is done in the go.mod and go.mod.license files)

Hi @gab-arrobo,
Yes, I'm testing the generator after every change to make sure the result is correct.
api.mustache.license added.

[gab-arrobo]

+1