...
- Is it expected both CPS REST and xNF Proxy are used to manage same data?
- Is the cache expected to be updated in order to support scalability (multiple instances of same application) and cases like described above?
There is a mention of CPS
Understanding of "deployment" and "
...
scripts" in a context of containers
In a context of containers the set of available actions on deployment is quite limited/complicated
Usually the deployment assumes
- Downloading an image
- Configuring the containerized application (using environment variables and/or configuration maps)
- Starting the image based container
- Using container management platform like Kubernetes or OpenStack
So it requires to be clarified:
- What's the meaning of "Deploy xNFProxy (co-deployed with CPS-Core)"?
- What's the meaning of "Execute scripts at deployment"? When exactly (on which deployment or application execution stage)
the script should be executed? Should it be executed within a container or it should be an external procedure?
Data Preset
addresses:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
It's expected the xNF Proxy has to use predefined dataspace, schema set (set of yang resources) and associated anchor (? see below)
in order to perform proper requests via CPS service API.
If the data preset is performed with external invocation, then it became necessary to somehow sync the externally provided data
with internal configuration to avoid settings being lost if container with the application is restarted.
So it seems reasonable to use internal configuration to preset values with ability to override values using container configuration
(env variables). The proposal (to confirm):
- dataspace, schema set and anchor names defined via application.yml configuration file (can be redefined using env variables)
- yang resources are provided as files (resources/ paths to are defined in configuration)
- on application start only the "set-if-absent" procedure is performed populating configured data if not yet in database
(using CPS service API)
pros:
- easy to implement, nothing is hard-coded
- same configuration settings used for data preset and
...
- regular requests over CPS API, no need to handle/sync externally provided data
- the logic of data preset (all-at-once) can be reused in subsequent updates
cons:
- yang resources cannot be updated without image rebuilt
xNF Proxy REST API methods and anchor input
The list of endpoints expected lists only method to fetch the data.
- Is it the only method expected?
- how the data (to fetch) will appear in database?
Regarding usage of anchor there are contradictions in expected functionality described:
- 'Create (1) anchor for E2E Network Slicing / Create Schema set (upload yang file) and apply to anchor' assumes anchor is a part of preset,
so it cannot be modified and not exposed in REST API - 'Endpoint to execute cpsPath query (get) for given anchor' assumes anchor name is provided as input; and it's not a part of of preset
so we need extra logic to maintain the anchor availability ('create if not exists') not only on application start but on request processing as well
It needs to be clarified
- is usage of multiple anchors (name provided on request via REST API) is expected?
- or the only anchor to be used (MVP), name predefined (configured)