feat: add Webconsole NFConfig API and models

[gatici]

5G SD-Core configuration system is being replaced with a new polling based design. Webconsole implements polling server using HTTPs and exposes new endpoints. This PR inserts new config APIs and model definitions to Openapi repository under webconsole path as they are different from existing SBI API's. Webconsole NFConfig API and models will be used by all NFs and webconsole during NFConfig polling server and client implementations.

[Copilot]

Pull Request Overview

Adds a new polling-based NFConfig API under the webconsole path, including OpenAPI definitions, generated Go server stubs, and model types.

• Introduces webconsole/webconsole-api.yaml with five GET endpoints and component schemas.
• Adds generated Gin router (routers.go) and default handler stubs (api_default.go).
• Creates individual model files (e.g. model_*.go) matching the OpenAPI components.
• Updates go.mod to include gin-gonic/gin and related dependencies.

Reviewed Changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
webconsole/webconsole-api.yaml	Defines new NFConfig endpoints and associated schemas
webconsole/routers.go	Configures Gin routes for each /nfconfig/* endpoint
webconsole/api_default.go	Provides placeholder handler implementations returning JSON OK
webconsole/model_*.go	Auto-generated model structs for each OpenAPI component
go.mod	Adds github.com/gin-gonic/gin and pruned dependencies

Comments suppressed due to low confidence (2)

webconsole/api_default.go:26

• This handler is a stub; add unit tests to verify routing, status codes, and correct JSON payloads for each endpoint.

func (api *DefaultAPI) NfconfigAccessMobilityGet(c *gin.Context) {

go.mod:7

• The go.mod lists many indirect dependencies; run go mod tidy to prune unused modules and keep the dependency graph clean.

github.com/gin-gonic/gin v1.10.1

[patriciareinoso]

I see this is generated using openapi which is useful. But I see a couple of issues:

1. The routes and handling methods belong in the webconsole, they should not be in this repo. It adds the gin dependency which I do not think is necessary here.
2. There is duplication in types that already exist in the model package. Does it mean that the NFs will use the webconsole type during polling but then, what type should they use to store the configuration ? (I would say the SBI one?).
   Should they then do conversions to get to the SBI types? (I think that if we align the json tags we can unmarshal in the types in models easily)

[patriciareinoso]

1. should we include somewhere the original yaml file that you use to generate the api ?
2. I think you need to run again go mod tidy to remove the packages included
3. what do you think about nfConfigApi as a package name ?
4. I am worried about the "omitempty" everywhere
   it means that we may pass

"mnc" : "123"

If MCC is not the defined.
But if we remove the omitempty it will be

"mnc" : "123",
"mcc":  "",

which is not great either. Go does not help us much with mandatory fields. But I think that we need to remove the omitempty in case of mandatory to at least make it evident when we read the type. WDYT?

I think we need

required:
        - mcc
        - mnc

and add --additional-properties=validateRequired=true to the generation command.

[gab-arrobo]

I thought that you also had to create an API but I do not see in the files that were generated. I only see models. Is it correct? or are the API(s) still missing? Additionally, for the models that already exist in the openapi/models directory, can you use them instead of creating similar models in the openapi/webconsole directory?

[gatici]

I thought that you also had to create an API but I do not see in the files that were generated. I only see models. Is it correct? or are the API(s) still missing? Additionally, for the models that already exist in the openapi/models directory, can you use them instead of creating similar models in the openapi/webconsole directory?

Hello Gabriel,

1. API file is also included with the last commits.
2. It is possible use some models from SBI in the NfConfig models. However @patriciareinoso and me have some concerns for the future model changes in the SBI part. nfConfigApi models are not expected to be changed frequently but we can not guarantee that SBI models stays as is. That's why we did not prefer to reuse them. WDYT ?

[gatici]

1. should we include somewhere the original yaml file that you use to generate the api ?

   2. I think you need to run again go mod tidy to remove the packages included

   3. what do you think about nfConfigApi as a package name ?

   4. I am worried about the "omitempty" everywhere
      it means that we may pass

"mnc" : "123"

If MCC is not the defined. But if we remove the omitempty it will be

"mnc" : "123",
"mcc":  "",

which is not great either. Go does not help us much with mandatory fields. But I think that we need to remove the omitempty in case of mandatory to at least make it evident when we read the type. WDYT?

I think we need

required:
        - mcc
        - mnc

and add --additional-properties=validateRequired=true to the generation command.

1. The original yaml that we used to generate the models are already included https://github.com/omec-project/openapi/pull/69/files#diff-6184ab7c09833d3848208e74f73fd34773b4f0f9613a762cdf7b93baf1069adc.
2. ok, Done.
3. nfConfigApi also looks good. I used it.
4. I generated the models with required fields. Thank you for the hint.

[ghislainbourgeois]

LGTM, I will let @gab-arrobo approve first before merging as he had comments.

[gab-arrobo]

@gatici, please rebase your PR

[gab-arrobo]

It seems a bit redundant that we need to have the models in both client and server. The models for both (client and server) are pretty much the same (from the struct perspective). Is not it possible to have a single set of models such that can be used by the client and server? What do you think @gatici, @ghislainbourgeois, @thakurajayL, @patriciareinoso?

[gab-arrobo]

@gatici,
Also, git apply is complaining about blank line at end of file and trailing whitespaces

$ git apply pr.patch
pr.patch:1859: new blank line at EOF.
+
pr.patch:2084: new blank line at EOF.
+
pr.patch:2211: new blank line at EOF.
+
pr.patch:2507: new blank line at EOF.
+
pr.patch:2760: new blank line at EOF.
+
warning: squelched 13 whitespace errors
warning: 18 lines add whitespace errors.

[gatici]

@gatici, please rebase your PR
It's rebased.

[gatici]

It seems a bit redundant that we need to have the models in both client and server. The models for both (client and server) are pretty much the same (from the struct perspective). Is not it possible to have a single set of models such that can be used by the client and server? What do you think @gatici, @ghislainbourgeois, @thakurajayL, @patriciareinoso?

Hello Gabriel,
You are right, although both server and client side parts are necessary, there is some redundant data. I changed this PR to store the shared data in a single folder so both sides can import it when necessary.

.
├── client
│   ├── api_default.go
│   ├── client.go
│   ├── configuration.go
│   ├── response.go
│   └── utils.go
├── nfConfigModels
│   ├── model_access_and_mobility.go
│   ├── model_arp.go
│   ├── model_direction.go
│   ├── model_dnn_qos.go
│   ├── model_ip_domain.go
│   ├── model_pcc_flow.go
│   ├── model_pcc_qos.go
│   ├── model_pcc_rule.go
│   ├── model_plmn_id.go
│   ├── model_plmn_snssai.go
│   ├── model_policy_control.go
│   ├── model_preempt_cap.go
│   ├── model_preempt_vuln.go
│   ├── model_session_management.go
│   ├── model_snssai.go
│   ├── model_status.go
│   ├── model_upf.go
│   └── utils.go
├── README.md
├── server
│   └── api_default.go
└── webconsole-api.yaml

[gab-arrobo]

client and nfConfigModels (models) look good to me. However, I do not quite understand how you are planning to use the server because by default the server does nothing. That is, when its API gets called, it always returns status OK and an empty array. Is this what you were trying to achieve? or what am I overlooking?

P.S. Sorry for the delay reviewing this PR (last week I was on a business trip and this week, I took a few days off

[gatici]

client and nfConfigModels (models) look good to me. However, I do not quite understand how you are planning to use the server because by default the server does nothing. That is, when its API gets called, it always returns status OK and an empty array. Is this what you were trying to achieve? or what am I overlooking?

P.S. Sorry for the delay reviewing this PR (last week I was on a business trip and this week, I took a few days off

Hello Gabriel,
No problem. Thanks for reviewing this again.
Regarding server default API, we are aiming to get the data by triggering a sync after every webUI request processing. We will create in-memory variables to store the configuration for each endpoint and those memory variables are updated after every sync. In the server default API, our response will include those memory variables. Please see the PR here: https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e

The function looks like this in the server implementation.

func (n *NFConfigServer) GetAccessMobilityConfig(c *gin.Context) {
	c.JSON(http.StatusOK, n.inMemoryConfig.accessAndMobility)
	logger.NfConfigLog.Infoln("Handled GET request for access-mobility config")
}

It is difficult to reflect this change in the Openapi repository. One option is removing server side and another is just keeping them as empty as a reference . What is your opinion on this ?

[gab-arrobo]

client and nfConfigModels (models) look good to me. However, I do not quite understand how you are planning to use the server because by default the server does nothing. That is, when its API gets called, it always returns status OK and an empty array. Is this what you were trying to achieve? or what am I overlooking?

Hello Gabriel, No problem. Thanks for reviewing this again. Regarding server default API, we are aiming to get the data by triggering a sync after every webUI request processing. We will create in-memory variables to store the configuration for each endpoint and those memory variables are updated after every sync. In the server default API, our response will include those memory variables. Please see the PR here: https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e

The function looks like this in the server implementation.

func (n *NFConfigServer) GetAccessMobilityConfig(c *gin.Context) {
	c.JSON(http.StatusOK, n.inMemoryConfig.accessAndMobility)
	logger.NfConfigLog.Infoln("Handled GET request for access-mobility config")
}

It is difficult to reflect this change in the Openapi repository. One option is removing server side and another is just keeping them as empty as a reference . What is your opinion on this ?

My preference is to just remove the server side because it is actually not used. The actual server is already part of the webconsole, as shown in the link you provided (https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e).
FYI, the SBI has a similar implementation. That is, the openapi repo has the clients and models for the different SBIs, while each NF has embedded the server side of the SBI

[gab-arrobo]

client and nfConfigModels (models) look good to me. However, I do not quite understand how you are planning to use the server because by default the server does nothing. That is, when its API gets called, it always returns status OK and an empty array. Is this what you were trying to achieve? or what am I overlooking?

Hello Gabriel, No problem. Thanks for reviewing this again. Regarding server default API, we are aiming to get the data by triggering a sync after every webUI request processing. We will create in-memory variables to store the configuration for each endpoint and those memory variables are updated after every sync. In the server default API, our response will include those memory variables. Please see the PR here: https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e
The function looks like this in the server implementation.

func (n *NFConfigServer) GetAccessMobilityConfig(c *gin.Context) {
	c.JSON(http.StatusOK, n.inMemoryConfig.accessAndMobility)
	logger.NfConfigLog.Infoln("Handled GET request for access-mobility config")
}

It is difficult to reflect this change in the Openapi repository. One option is removing server side and another is just keeping them as empty as a reference . What is your opinion on this ?

My preference is to just remove the server side because it is actually not used. The actual server is already part of the webconsole, as shown in the link you provided (https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e). FYI, the SBI has a similar implementation. That is, the openapi repo has the clients and models for the different SBIs, while each NF has embedded the server side of the SBI

@gatici,
If you end up removing the server side, there may be no need to have the client and models in different directories. You can have all of them in a single directory. For example:

.
├── api_default.go
├── client.go
├── configuration.go
├── response.go
├── utils.go
├── model_access_and_mobility.go
├── model_arp.go
├── model_direction.go
├── model_dnn_qos.go
├── model_ip_domain.go
├── model_pcc_flow.go
├── model_pcc_qos.go
├── model_pcc_rule.go
├── model_plmn_id.go
├── model_plmn_snssai.go
├── model_policy_control.go
├── model_preempt_cap.go
├── model_preempt_vuln.go
├── model_session_management.go
├── model_snssai.go
├── model_status.go
├── model_upf.go
├── utils.go
├── README.md
└── webconsole-api.yaml

[gatici]

client and nfConfigModels (models) look good to me. However, I do not quite understand how you are planning to use the server because by default the server does nothing. That is, when its API gets called, it always returns status OK and an empty array. Is this what you were trying to achieve? or what am I overlooking?

Hello Gabriel, No problem. Thanks for reviewing this again. Regarding server default API, we are aiming to get the data by triggering a sync after every webUI request processing. We will create in-memory variables to store the configuration for each endpoint and those memory variables are updated after every sync. In the server default API, our response will include those memory variables. Please see the PR here: https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e
The function looks like this in the server implementation.

func (n *NFConfigServer) GetAccessMobilityConfig(c *gin.Context) {
	c.JSON(http.StatusOK, n.inMemoryConfig.accessAndMobility)
	logger.NfConfigLog.Infoln("Handled GET request for access-mobility config")
}

It is difficult to reflect this change in the Openapi repository. One option is removing server side and another is just keeping them as empty as a reference . What is your opinion on this ?

My preference is to just remove the server side because it is actually not used. The actual server is already part of the webconsole, as shown in the link you provided (https://github.com/omec-project/webconsole/pull/372/files#diff-526559336b1b69c60bd13f658627f5406de0bbe1254cc316ed4cf57c8f44ff9e). FYI, the SBI has a similar implementation. That is, the openapi repo has the clients and models for the different SBIs, while each NF has embedded the server side of the SBI

@gatici, If you end up removing the server side, there may be no need to have the client and models in different directories. You can have all of them in a single directory. For example:

. ├── api_default.go ├── client.go ├── configuration.go ├── response.go ├── utils.go ├── model_access_and_mobility.go ├── model_arp.go ├── model_direction.go ├── model_dnn_qos.go ├── model_ip_domain.go ├── model_pcc_flow.go ├── model_pcc_qos.go ├── model_pcc_rule.go ├── model_plmn_id.go ├── model_plmn_snssai.go ├── model_policy_control.go ├── model_preempt_cap.go ├── model_preempt_vuln.go ├── model_session_management.go ├── model_snssai.go ├── model_status.go ├── model_upf.go ├── utils.go ├── README.md └── webconsole-api.yaml

Hello @gab-arrobo, I removed the server side and consolidated models and client in the same folder.

[gab-arrobo]

Do you need to create a major, minor or patch release (i.e., change the VERSION file)?

[gab-arrobo]

Do you need to create a major, minor or patch release (i.e., change the VERSION file)?

Hi @gulsum,
I made two commits in your PR: 1) Apply go mod tidy to remove unneeded dependencies; and 2) Create a minor release such that these changes can be used in the other repos

[gab-arrobo]

LGTM