Versions Compared

Old Version 11

changes.mady.by.user aditya puthuparambil

Saved on

compared with

New Version 12

changes.mady.by.user aditya puthuparambil

Saved on

Key

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

...

Three different implementation proposals as below:

...

#DescriptionNotesProsCons
1

Each component contains its own docker-compose file listing all the services required for the integration test. Eg : cps-temporal docker-compose would have

...

services  from cps-temporal

...

as well as cps-core

As all the services are included in the docker-compose of cps-temporal, CSIT test setup could directly trigger :

      docker-compose up


  • Faster implementation

Pros:

  • Faster implementation

...

  • Every change made in a single service would have to be duplicated in all the other files where the same service is used like addition of new environment variables.
  • Harder to maintain
2

...

 Each component contains its own docker-compose file with the services required for stand alone testing. Eg: cps-temporal docker-compose only containing services cps-temporal, timescaledb, zoopkeeper and kafka. 

As cps-temporal is a client using cps-core, include steps to fetch the docker-compose of cps-core in the cps-temporal setup.sh file in CSIT as shown below:

      git clone https://github.com/onap/cps.git

Combine the docker-compose of cps-temporal and cps while executing 'docker-compose

...

up' 

     docker-compose -f docker-compose.yml -f ../cps/docker-compose/docker-compose.yml up

...

  • No need for code replication.
  • docker-compose files specific to each component

...

  • Cloning the dependent repo
3

...

Create a repo for all the common artifacts like the CSIT, documents. Sub modules could be created for different components inside CSIT to include both the docker-compose and test plan.

Eg: cps-temporal CSIT would combine the docker-compose of cps-temporal and cps-core while executing 'docker-compose up' as below :

     docker-compose -f docker-compose.yml -f ../cps/docker-compose.yml up

...

  • No need to replicate the docker-compose
  • docker-compose files specific to each component maintained in different sub modules
  • No cloning required for the dependent repo to run CSIT

Cons:

...

  • ci-management jobs will have to be created, hence time consuming for now
  • Manageability of an additional repo .


Test Plan:

S NoScenarioSteps Status
CPS

1.1
CPS Admin Details Insert
  1. Create Dataspace 
  2. Create Schema set with Zip file
  3. Get schema set 
  4. Create anchor for the created schema-set and dataspace
  5. Get Anchor
To Be Updated
1.2CPS Data Node Insert, Update and Delete
  1. Create Data Node for an anchor
  2. Get Datanode by the dataspace, anchor and xpath
  3. Update data node
  4. Get data node using the Query API to ensure the update data node is fetched.
  5. Delete the created data node
  6. Get Datanode by the dataspace, anchor and xpath to ensure the 
To Be Updated
CPS Temporal
2.1Create an anchor history
  1. Create Data Node using cps api 
  2. Update the Data Node using cps api
  3. Get the history of the anchor using cps-temporal api 
    /v1/dataspaces/{dataspace-name}/anchors/{anchor-name}/history

2.2Delete the data node to add it to history
  1. Create Data Node using cps api 
  2. Update the Data Node using cps api
  3. Delete the data node using cps-api
  4. Get the history of the anchor using cps-temporal api 
    /v1/dataspaces/{dataspace-name}/anchors/{anchor-name}/history

CPS-NCMP-DMI_PLUGIN
3.1

Model-Sync, Write & read data using datastore PassTrough

  1. Create Data Node using cps api 
  2. Notify NCMP DMI has new node 
    1. http://localhost:8783/dmi/api/v1/inventory/cmHandles
    2. This will kick off model sync as part of registation
  3. wait till above method call completes and send a 2xx response
  4. Show data in Postgres: anchor and module-set
  5. Use CPS endpoint that shows anchors & namespaces to conclude test completed
    1. <ENDPOINT TO BE CONFIRMED>





...