/
CPS-78: Deployment View

CPS-78: Deployment View

Current View



The following diagram represents CPS development view for components implemented in the PoC.







Service Data Registry, State, xNF Proxy components will need to be added to enrich the diagram and show where they are running (pod, container, application server)

Alternative deployment options

One of the purposes of having both Java and REST interfaces is to enable flexibility in deployment.

It has not been decided which deployments will be supported — yet!

The deployment flavors are not mutually exclusive.

The JDBC parameters need to be configurable — right now we do not know if CPS will use an existing DBMS or a dedicated instance. Going forward, it may be that different instances require (for security purposes) dedicated instances of the DBMS. It may also be that different instances need to share access to the same DBMS (say for horizontal scale)

I can see no good reason to have multiple JDBC connections when we introduce the CPS NF Proxy functionality.

Bundling/coupling the build (the creation of the image) in the cps-rest does not work for this level of flexibility — several different (µS image) build instructions are needed.

I do not get the 1:1 relationship between the SpringBootApplication and the REST interface above. If the code is in separate SpringBootApplications, what is the invocation overhead introduced by Spring to resolve the implementation of an interface?



  1. Standalone

    • Scenario: Need to store non-NF data

    • Basic YANG data storage

  2. CPS NF Proxy

    • Scenario: Need to access NF CM data quickly (cache) and also store application data (E2E network slicing)

    • Basic YANG data storage

    • NF CM data storage (requires co-deployment to avoid communication (serialization/de-serialization) overhead

  3. CPS NF Proxy, Temporal

    • Scenario: The temporal stack is interested in NF CM data

    • Basic YANG data storage

    • NF CM data storage (requires co-deployment to avoid communication (serialization/de-serialization) overhead

    • Temporal data storage/access (requires co-deployment to avoid communication (serialization/de-serialization) overhead

  4. Separated

    • Scenario: The frequency/volume of data of interest to the Temporal stack is low

Related content

CPS-168 xNF Proxy Epic - MVP delivery clarification
CPS-168 xNF Proxy Epic - MVP delivery clarification
More like this
CPS-1964 - Support for Async datajobs Write
CPS-1964 - Support for Async datajobs Write
More like this
ARC Configuration Persistence Service (CPS) Component Description - Honolulu-R8
ARC Configuration Persistence Service (CPS) Component Description - Honolulu-R8
More like this
ASD PoC Use Cases & Requirements
ASD PoC Use Cases & Requirements
More like this
CPS Specifications
CPS Specifications
More like this
CPS-391Spike: Define and Agree NCMP REST Interface
CPS-391Spike: Define and Agree NCMP REST Interface
More like this