Page Comparison

Addresses: 

Initial description:

...

It was mentioned several times the xNF Proxy will interact with CPS using Java API. It means the only possible
way of integration is embedding the cps modules as jars  int xNF Proxy web application as it's described in 
CPS-171 CPS xNF-Proxy Deployment and module dependencies and being implemented via

This approach requires confirmation.

...

• 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: 

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 to be provided on request via REST API) expected?
• or the only anchor to be used (MVP) is the one with name predefined (configured)