Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Addresses:  CPS-168 - Getting issue details... STATUS

Initial description:

  • Create minimal xNfProxy REST service
  • Scripts to
    • Create dataspace 
    • Create (1) anchor for E2E Network Slicing
    • Create Schema set (upload yang file) and apply to anchor
  • Create Rest API with
    • Endpoint to execute cpsPath query (get) for given anchor
  • Deploy xNFProxy (co-deployed with CPS-Core)
  • Execute scripts at deployment 

Out of scope:

  • xNfProxy - CPS communication issues ie. CPS down
  • Security & Authentication

Questions

xNF Proxy to CPS connection / integration approach ?

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
CPS-171 - Getting issue details... STATUS

This approach requires confirmation.

Using CPS as embedded logic for both xNF Proxy and CPS REST application at same time may cause issue with cache: current cache of
SchemaContext is not shared across containers. It means it's possible to update the schema set (yang resources) using CPS REST
while cache within xNF Proxy remain outdated. 

So the following requires to be clarified (in a context of MVP and further development)

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

Understanding of deployment and "script" in a context of containers and data presets


xNF Proxy API methods and anchor input usage





  • No labels