I've created the following slide deck to describe the highlights of ONAP Dublin release. These include all the Use Cases, as well as Project level summaries. 

I would like to invite community members to review and let me know of any misrepresentation/incorrect/missing information. 






Regards, 

Sriram






  • No labels

19 Comments

  1. Good initiative.

    Anyway to avoid adding new tasks to PTL, I believe that we should rely on project release notes to extract the material

  2. Sriram Rupanagunta  - DCAE Dublin updates captured is not complete; please include below.

    • New microservices suite of collectors/event processors/analytics:
      • Collectors: RESTConf collector
      • Event Processors: VESMapper, PM-Mapper, BBS-EventProcesor
      • Analytics/RCA: SON-Handler,Heartbeat
    • Common SDK for DCAE components
    • Multisite K8S cluster deployment support for DCAE services (via K8S plugin)
    • Support helm chart deployment in DCAE using new Helm cloudify plugin
    • DCAE Healthcheck enhancement
    • Dynamic AAF based topic provisioning support through Dmaap cloudify plugin
    • Dashboard Integration (UI for deployment/verification)
    • PolicyHandler Enhancement to support new Policy Lifecycle API’s
    • Blueprint generator tool to simplify deployment artifact creation
    • DCAE component enhancements for security, logging, resilience enhancements
  3. user-67d6f

    Updated on VTP, CLI and related functional updates

  4. I have addressed all the comments I received so far, and updated the presentation. 

    I will also go over the Release notes, to make sure all major features are captured. 

  5. user-67d6f

    Sriram Rupanagunta I have updated the changes made  in v3 into v4 version. Thanks

  6. Sriram Rupanagunta I have updated the version for SO and uploaded V5

  7. Additional feedback

    • Slide 15, please add
      • Opendaylight fluorine SR1 upgrade
      • Multiple standalone ansible server support
    • Slide 18 "for model drive configuration" to be changed as "for model driven configuration"
  8. Concerning Control Loop part, can you please contact Scott Blandford , Pamela Dragosh and Marco Platania since additional enhancements are required - thank you

  9. A few additional comments

    Slide 3:

    k8s based cloud region support

    Container based Network function support in Multicloud

    We must be careful. We do not provide the full capability to onboard and deploy a CNF using ONAP.

    Slide 4: I have a better quality image:




    Slide 5: clarify HSIA (High Speed Internet Access) ?

    Slide 6: We must be careful about Newtork slicing.

    Sldie 12: typo: VSP Compliance Check

    Slide 27:

    • Security via Envoy (northbound), Network Policy (east-west) => Not available for Dublin


    There is nothing about non functional requirements: Dublin Release Requirements

    E2E Automation

    • Dublin has evolved the controller design studio, as part of the controller framework, which enables a model driven approach for how an ONAP controller controls the network resources.


    Footptrint optimization

    • Docker optimization
    • Sharing DB

    Security

    • xNF communication security enhancements.
    • oParent Integration to fix vulnerabilities
    • Securiy by design improvements

    CI/CD Improvement with OOM gating


    Globally, we should be aligned with the last Architecture description:

    https://logs.onap.org/production/vex-yul-ecomp-jenkins-1/doc-master-verify-rtd/4866/html/guides/onap-developer/architecture/onap-architecture.html#onap-architecture






  10. Please update  the VF-C update for Dublin highlight

    Dublin-Highlights-v1-VF-C-update-v1.pptx


  11. Thanks for all the comments received so far. 

    I have updated with all the comments (v6 version of slides). 

  12. Sriram Rupanagunta  - here is an updated deck (v7)

    Slide 3:

    • Use Case → Requirements
    • Consistent ID of Cloud Region has been deferred to another release (Test completion not finalized)
    • A lot of POCs were performed during the Dublin timeline but we have not been informed about their progress, neither of their results. No reference in the release note.

               Therefore POCs should not be part of the Dublin Highlights messaging deck.

    Slide 4 – change the verbiage for E2E automation. E2E automation is more about SO and CDS integration for post instantiation to enable zero touch provisioning.

    Slide 5 – added for CDS. Let me know what you think:

    The basic message is that

    1. CDS is a cloud native microservices controller solution that is Kubernetes friendly.
    2. CDS lives in CCSDK and reusable across different controller personas.
    3. CDS helps enable Zero Touch Controller Declarative Provisioning.
      1. Enabling Platform use cases such as vDNS E2E Automation, Scale Out Etc..
    4. I didn’t include the message about cross organizational implementation such as Bell C, Orange, IBM, DT etc..

    Slide 12 - has been removed since it has been deferred to another release

    Slide 17: CLAMP is not integrated with ODL; no Ansible server support

    Slide 30: APEX is not new. Please consider Pam Dragosh & Scott Seabolt's feedback

    Slide 44: Delete the line related to Consistent ID of a Cloud Region


    Additional feedback/question

    Slide 2: BBS, CCVPN - Value in Dublin - no change based on the reduced scope?

    Slides 3/4: Shall we try to align the content of this slide with the slides 12 &13 of the LFN ONAP Dublin PR v7.1?

    Slide 7: Please align BBS content with the reduced scope

    Slide 9: Please align CCVPN content with the reduced scope

    Slide 11: Please consider Pam Dragosh & Scott Seabolt's feedback

    Slide 43: To be reviewed based on BBS/CCVPN reduced scope


  13. Thanks, Catherine. 

    I have added couple of updates (cleanups) and added a slide on ETSI compliance, and include Pam/Scott's feedback. I uploaded v8 version of slides. 

    I will do another round of review of other comments from you and align them with messaging document. 

  14. Sriram Rupanagunta


    I see this: 


    I did not understand the red statement. 

    I like to see following in the description:

    •  Onboarding of VNFs and CNFs with helm charts and deployment of VNFs and CNFs on Kubernetes based sites.


    In the 'Functional capability - K8S based Cloud region support" slide, I would go with following:

    • Onboardiing of VNFs and CNFs in SDC 
    • Deployment of VNFs and CNFs in K8S based Cloud regions via VID and SO.
    • Support for creation of multiple networks.
    • Placement of VNFs and CNFs on multiple networks.
    • Co-existence of VNFs and CNFs in the same K8S cluster sharing the networks.
    • Use cases verified
      • vFW use case (without closed loop) where packet generator & firewall are deployed as VNFs and sink is deployed as CNF.
      • EdgeXFoundry use case - IOT platform deployment in K8S based Cloud regions.
  15. Thanks Sriram Rupanagunta , 

    a few comments about v8

    in slide 8: 

    "HSIA service subscription plan changes & service assurance" was not implemented in Dublin, is meant for future releases

    in slide 44:

    CLAMP is not used/impacted by BBS in Dublin, we plan to make use of it in future releases
    As far as I know, OSAM is not a use case in Dublin

  16. Uploaded v9 version (with all comments incorporated). 

  17. Uploaded v10 about Modeling subcommittee Dublin Progress based on the consensus of modeling subcommitee:

    ONAP Modeling Subcommittee Dublin Release Highlights

    Updated the modeling project