You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 42 Next »

Prerequisite

https://wiki.onap.org/display/DW/Controller+Design+Studio+%5BCDS%5D+Documentation

Face 2 Face Controller Design Studio Agenda


  • The ONAP CDS developer communities will be coming together at the Bell Canada facility in Montreal Canada. 

Contact Information:

Name

Email

Session Virtual/In-Person

ali.daher@bell.caIn-Person

In-Person

In-Person

In-Person

In-Person

In-Person

In-Person

In-Person

In-Person




Yuriy.Malakov@att.comIn-Person

In-Person
Eric Multanen
In-Person
Adil Mir
In-Person

In-Person
Kirill Lukashin
Virtual

Agenda for the week of August 26th 2019


NOTE: Monday and Tuesday session will happen in Downtown Montreal for ease of travel to most of those joining out of town. Wednesday session will take place at Nuns Island to allow a go and see to the Bell campus where the ONAP squads are located.  

Monday 


Tuesday 


Wednesday 


NEWTON ROOM 8th floor- 671, rue de la Gauchetière O. MONTREAL PQNEWTON ROOM 8th floor- 671, rue de la Gauchetière O. MONTREAL PQRoom E1.2 1, carrefour Alexander-Graham-Bell VERDUN - CAMPUS MONTREAL PQ, H3E3B3,
09:00AM

Welcome, Introduction, logistics, overview of Agenda and CDS roadmap.  Adjust Agenda if needed 


Join Webex meeting

Dis-aggregation of CDS Resource Resolution from Blueprintprocessor


Join Webex meeting


Go and See of Bell ONAP squads 



09:30AMCDS multicloud support
10:00AM
10:30AM Break Break Break
10:45AM

CDS Test Strategy

Align test coverage with CDS features upgrades

Add CDS Health Check for Robot

Add a black box test case for CDS via Robot

Add a use case test case for CDS via Robot

UAT test 


Join Webex meeting


CDS: Queue Mechanism/Priority Execution


Join Webex meeting

Resource LCM  Resolution

VNF LCM Resolution, SO role


Join Webex meeting


11:30AM
12:00PMLunch

Lunch


 Lunch

 

12:30PM
1:00PM

AAF Integration with Blueprint processor /Controller blueprint

Refactor Logging in CDS components to integrate full error management (error handler and error code)


Join Webex meeting


CDS. Atomic Transaction for Multi Device level connection 


Join Webex meeting

CDS capabilities in Frankfurt to meet 5G requirements


Join Webex meeting


1:30PM

Intent implementation in CDS 
2:00PM
2:30PM
3:00PMBreak Break Break 
3:30PM

CDS security and gRPC TLS/Authentication 


Join Webex meeting


(Buffer: DSL topic) 


CDS Mediation Layer: Store the configlet content that is pushed to network via Ansible/Python in a database as a service. Retrieve configlet content form Ansible/Chef etc.. 


Join Webex meeting


CDS Policy and roadmap. 



Join Webex meeting

4:00PM

4:30PM
5:00PMGeneration of the OPEN-API google protobuff specification for CBA Packages. 
5:30PM
6:30-8PMTeam Dinner: Moxies, 1207 Boulevard Robert-Bourassa, Montréal, QC H3B 0C3Retrospective around the workshop (check and adjust) + Team Dinner 

Retrospective around the workshop

Meeting Minutes: 

Meeting Minutes:

  1. gRPC CDS Integration
    • Action Item:
      • Yuriy to create a US for Frankfurt to move all the CDS UI API leveraging the blueprint processor for enrich , save, publish, download
    • NOTE: Work remaining for the integration of the controller blueprints capabilities in blueprint processor
    • In Dublin release gRPC not supported by Controller blueprints
    • Frankfurt release there is an effort to combine the controller blueprints with blueprint processor. Blueprint processors support gRPC endpoints.
  2. Event Based Message integration with CDS
    • CDS à Kakfa/Dmaap
    • Kafka/Dmaap à CDS
    • Action Item:
      • Work with Abdel/Ali/Alexis on show casing this capability  in ONAP.
    •  Use Case need to be show cases in ONAP. Bell C has up streamed the Kafka and Dmaap support in ONAP with CDS integration.
  3. Health Check Strategy
    • Action Item:
      • Yuriy to work with Abdel to support the health check integration with new health check API
      • Alexis to provide guidance on the standardize on the health check implementation for all the endpoint and provide the output via a single api. Janani??
    • The current health check API only checks the self service API. In Frankfurt release, the proposal is to expose endpoint that will be able to do all the health check api for all the cds design time and run time functions.
  4. Testing Strategy:
    • 1. Verify Job integration the sonar check to prevent new code from being submitted  --> refining the JJ-Job --to define the Jenkins job builder. Prototype....
      • Yuriy to setup a call with Jessica include Ebo, Alexis, Dan T, Prat
      • Ebo to look into the tool to help provide a clear view on the health of the project before integration.
      • Ebo add the capability for testing UAT Test as part of the run time. (Mock vs real ENV). combination of the run time output and Mock expectation output using the run time results. --SELF SERVICE CSIT for enriched CBA as part of run time execution.
      • Yuriy to work with Ebo to extended the UAT Test file to vLB and vFW use case.
      • Ebo to extended the declarative testing to enrichment validation for CBA Package.
        • No Enrich Blueprint > Validate Enrichment process;
      • Arundathi and Ebo to enable the Testing folder to allow a list of UAT files for verifying list of actions.
        • Multiple file for UAT--is expecting --> we should have a pattern for each of the UAT and actions.
      • NOTE:
        • Automatically create serverless function --running a build --Docker Image deploy > Kick off testing and returning test results.
        • Providing mock information FOR EXTERNAL SYSTEM. Mock Packages.
        • Technology YAML > YAML error prone?  DSL Domain Specific language. Brinda recommendation
        • General Comment from Dan T: No permission to disable false positive discovery by sonar. --talk to Jessica
        • Move integration test to unit test
        • integration test –
        • Unit Test --- complimentary to acceptance test
        • Acceptance test --- ete test with external testing.
        • UAT Testing of the CBA critical to verify the backwards compatibility and introduction of new features.
        • Select the ENV to run---
      • Linux foundation support might be needed...to have sonar analysis the new code coverage
      • Action Item:
    • Test Coverage -->
    • ideas   
  5. Heat Bridge
    • Munir to contribute the heat bridge so implementation for create A&AI object which include the pserver object creation.
    • Munir  contribute the heat bridge so implementation to delete the A&AI object as part of the delete flow.
    • Action Items:


  1. CDS & AAF Integration
    • CBA support the notion of adding new action which needs to be correlated to the list of users that might be able to executed as part of the design time activity.
    • Brinda to provide update to Mike on the AAF/Service Meshing integration. Brinda to share AAF documentation for CBA Package integration notion.
    • Yuriy to add Mike to the thread for AAF Integration
    • Yuriy to setup a call with Ajay S on the call NPM Implementation of user role management via AAF REST API layer.
    • Yuriy to add a roadmap item for CDS UI and AAF Integration for User Role Management –ADMIN User needed??? Placeholder
    • Henry to add a flag to turn off aaf
      • If aaf is disable then http is supported.
    • NOTE:
      • New Servlet version à Intercept concept is supported with version 3.0.
      • Bell Canada is leading effort for service mesh/ISTO
      • Need to be bound to AAF, Service Meshing and ISTO
      • Mike à ISTO/Service Meshing support à What is possible Frankfurt ???
      • Endpoint role management à Web flux (non-block integration) ???
      • Service mesh and ISTO
    • Namespace Creation and User Role Management is managed with AAF
    • CBA Package should include reference to the AAF Namespace for role and users that are able to execution the CDS action within the CBA context. Each CBA might have a unique or shareable namespace. This implementation should be implemented via REST Layer.
    • Action Items:


 

  1. Platform CDS Logging, Tracing, and Error Modeling
    • Error Code to Error message mapping within a component
    • All Error code and messages need to be document with hints of common remediation/resolution
    • Aggregated all the errors and make sure if an error occurs its tied to error code.
    • Platform Error à  Derived from NodeTypes.
    • Parallel process request error à capture multiple error and aggregate back to the users.
    • Ebo provide link to à
    • Event based logging needed for CDS Platform. Logging message event. (Request to maintain all the chain) (Diary of events) Request , Blueprint name, version.
    • Application performance monitoring à Tracing tracking the run time actions within the CBA. 
    • Benefits: what are the benefits.
    • ELK à provides but not opensource.
    • Alexis looking at alternative.  à Zipkin is opensource. (Elizar provide this as well)
    • Resource à Required ???     
    • Error Modeling  à
    • Logging:
    • Tracing à


  1. CBA Specification Generation [Janani??]
    • As part of the enrichment process generate a spec using a template engine.
      • Create a folder to store
      • Template Engine for a Version
        • OPEN-API
        • Google Protobuf (gRPC Client)
        • TOSCA à
        • Any model
      • Which version to generate à
        • Action Item: Rashmi to bring this topic up with CLAMP UI Team.
          • Options: gRPC and OPEN-API
        • CLAMP UI support TOSCA rendering???
      • NOTE:
      • Spec genereation


  1. Frankfurt Controller Blueprints implementation consolidation into controller blueprint processor.
    • Yuriy to create placeholder US to cover the below UI Scope planned for Frankfurt release:
      • Serverless function create an dynamically image and deploy with native k8s API. [Roadmap Item]
      • Spin up new blueprint processor only in testing environment and not in production is expected.
      • Serverless function allows you to build image on the fly.
      • Assumption: Production will have a stable set of containers/pod.
      • CDS UI to call the CDS Blueprints designer apià     
      • CDS UI to discover the blueprint process instance à Configuration management  [roadmap.  item]
      • CDS UI to spin up run time.  [Roadmap item]
      • NOTE:
    • Action Item:


  • blueprints management -- Pending work items
    • Combine the two table for where we store the design time and runtime…. Frankfurt Release à
      • One instance of blueprint processor to manage the package for all CBA à Master  [Frankfurt Roadmap]
    • Design time & Run time validation  is standalone  today but need to combine validation for design time and run time.
    • Need a flag to retrieve the CDS Blueprint cba package from a file path [mounted to a file path ]
    • Action Item:
    • Brinda is finalizing the implementation for following items:  


  • DSL Concept à Multiple CBA file
    • DSL and JSON file should keep constant reference for cds_model_name and cds_model_version.
    • As part of the distribution the onap component should extract the cds model name and version from a constant sdc tosca service.
    • Keep the constant name from SDC, SO, and CDS.
    • Work with Nokia on this implementation.
    • SDC and CDS Integration à Frankfurt


    • Action Item:
      • CDS UI should enforce the populate using the tosca meta file.
      • For CBA Package reference based on the tosca meta data.
      • Brinda to change template_model and template version to CBA_MODEL_NAME and CBA_MODEL_VERSION.
      • Yuriy to create requirement for UI team:
      • Alexis to support Migration of existing CBA in Bell from json blueprints tosca meta data to tosca file meta section for frankfurt.


  1. Other TOPICS:
  • Enable grpc and rest both? Brinda and Alexis ? Is this possible. Proxy Port.
  • Netty Listerner Proxy
  • One Server with two instances???one for gRPC and one for REST?? Challenge ? Benefits
  • Kafka  ? Can we remove spring layer?
    •  Alexis to check the idea.
    • Action Item: Brinda to provide doc to Alexis.


  1. MultiCloud/VIM and CDS Integration 
    1. Instatition Alignment
      1. agreement is that the VM and CNF Building Block orchestration should be common with the only difference is that SO as part of Create Building Block shall call trigger MultiCloud/Vim adapter for helm creation for the pod. 
    2. LCM Action
      1. CDS shall call the multiCloud/VIm Openstack Keystone v3 API or k8S based API for LCM Cloud actions. 

Logistics: 

Monday and Tuesday: 

https://www.google.com/maps/place/671+Rue+de+la+Gauchetière+O,+Montréal,+QC+H3B+2M8/@45.5014373,-73.5675914,17z/data=!4m13!1m7!3m6!1s0x4cc91a5b4471d7b7:0x88612655a88e21d0!2s671+Rue+de+la+Gauchetière+O,+Montréal,+QC+H3B+2M8!3b1!8m2!3d45.5014373!4d-73.5654027!3m4!1s0x4cc91a5b4471d7b7:0x88612655a88e21d0!8m2!3d45.5014373!4d-73.5654027

Wednesday: 

https://www.google.com/maps/place/Campus+Bell+(de+la+Pointe-Nord%2FJ.-Le+Ber)/@45.4723884,-73.6100177,12z/data=!4m16!1m10!4m9!1m1!4e2!1m6!1m2!1s0x4cc9100a7e06f11f:0x3f23d9830b59c387!2sbell+campus+nuns!2m2!1d-73.5399779!2d45.4724098!3m4!1s0x4cc9100a7e06f11f:0x3f23d9830b59c387!8m2!3d45.4724098!4d-73.5399779


  • No labels