Versions Compared

Key

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

...

Projects NameOOMNotes
Health CheckPASSED
  • Tested on Local microK8S with OOM

The healthcheck done on the frontend is propagated to the backend, therefore it validates both at the same time.

CLAMP ↔ DCAE (SB-0001)

IN PROGRESSPASSEDFrom
  • Tested on local Clamp to Windriver DCAE (10.12.7.33:30471)

Deploy / Undeploy test

done

DONE with TCA blueprint

  • Tested on SB-01, issue detected
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCLAMP-804
  • After the fixes new test with TCA, DCAE deploy operation has been started on DCAE as we can see here:
  • Image Added
  • Operation has been reported by DCAE as SUCCESSFUL as we can see hereImage Added
  • Undeploy has been tried as well and was successfully executed by DCAEImage Added
  • Bug found for undeploy status
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCLAMP-807
    but there is a workround
CLAMP ↔ Policy (SB-0001)IN PROGRESSPASSEDFrom
  • Tested on local Clamp to Windriver Policy (
  • 10.12.6.1:30210) Submit / Deploy OK - Stop / Restart OK  - PDP group selection and update in the different policies OK - Policy model synchronization, so policies available for loop instance OK - UI generation from policy models OK
  • Tested on SB-01,
  • Policy synchro (Dynamic policies based on tosca model) OKImage Added
  • Status of the policies (SENT AND DEPLOYED) after having added a frequency limiter policy (tested with Apex too)
    • Image Added                                                        Submit / Deploy OK
    • - Stop / Restart
OK
    • OK  - PDP group selection and update in the different policies OK
    • - Policy model synchronization, so policies available for loop instance OK
    • - UI generation from policy models OK.               Bug found and Fixed
      Jira
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyCLAMP-801
    • Bug found when re-submitting the policies
      Jira
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyCLAMP-808
      but there is a workaround
CLAMP ↔ SDC (SB-0001)IN PROGRESSPASSED

Tested

Must be done

on SB

01 once the lab will have been updated with the latest clamp

-01, Distribution done with the new DCAE blueprint TCA, the loop template was available, so it was possible to create a loop instance and submit to policy

Image Added

Artifacts deployed 2 so it's well ok for CLAMP, the template is well in the CLAMP DB

Image Added

It prooves the communication with DCAE at this point is also ok, artifact well deployed by SDC on DCAE

CLAMP  → AAF (SB-0001)IN PROGRESSPASSED
  • Tested on Local microK8s with OOM
  • Tested on SB-01, authentication successful with P12 certificate
  • Image Added
  • All permissions are well retrieved
  • Image Added
Must be done on SB 01 once the lab will have been updated with the latest clamp
CLAMP ↔ CDS (SB-0001)IN PROGRESSPASSED
  • Tested Locally by Vidya
  • Tested on SB-01
  • Sdc distribution of the right artifact (triggering CDS), the one selected here:
  • Image Added
  • After creating a Loop instance from that template, we have added an APEX policy model (got from policy), the policy config UI well show the CDS info for the payload field:
  • Image AddedThe remaining bug in that area is
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCLAMP-809
This requires additional testing on SB-01