Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#

Issue

Notes 

Decision

1Which operation(s) need support for multiple cm handles?
  1. Get
  2. Create
  3. Update (Put)
  4. Patch
  5. Delete

if many what is the priority?


1

Do we need to use same xpath (resourceIdentifierInQuery) for all cm handles or different for each cm handle ?




2

Which datasources ?

Do we need to support passthrough-only no-cached() data only ?

or, alternatively, support operational/running (cached) data too ?



Endpoint url patterns?

Existing : /v1/ch/{cm-handle}/data/ds/{datastore-name}

CPS Propossed : /v1/batch/data/ds/{datastore-name}

      ( include cm handles into payload / body and leave datastore into url)



keep datastore, topic and optional parameters in the URL itself instead into body.

CPS prefers keep interface similaral as single cm handle interface (consistency and cost)&topic=topicParamInQuery
3

Impacts on DMI Plugin Interfaces

    1. support in ONAP DMI-plugin


4

How we are supporting multiple anchors into CPS-Core ?

    1. Java Interface (depend on 2.1) or,
    2. REST Interface


5

Response always Async ie. topic is compulsory ?

    1. Reuse existing topic


<Note. use green for closed issues, yellow for important ones if needed>

Implementation :

#

Steps

Notes 

Decision

1

Define new get operation "getResourceDataForCmHandles" into ncmp.yml




2

Implement org.onap.cps.ncmp.rest.controller.NetworkCmProxyController#getResourceDataForCmHandles

with params below :

final String datastoreName,
final Collection<String> cmHandles,
final String resourceIdentifier,
final String optionsParamInQuery,
final String topicParamInQuery,
final Boolean includeDescendants
3

Impacts on DMI Plugin Interfaces

    1. support in ONAP DMI-plugin
4

How we are supporting multiple anchors into CPS-Core ?

    1. Java Interface (depend on 2.1) or,
    2. REST Interface
5

Response always Async ie. topic is compulsory ?

    1. Reuse existing topic


< we do not want to dictate the remainder of an analysis it will depend on the type of user story at hand>

...