Page Comparison

cl664y@att.com

Yang Xu

Amy Zwarico

Casablanca Maintenance Release Dashboard: https://jira.onap.org/secure/Dashboard.jspa?selectPageId=11102

Integration Blocker(s): Casablanca Maintenance Release Integration Test Blocking Issues

Integration Status: Casablanca Maintenance Release Integration Testing Status

Security - No blockers known.

TSC Recommendations: Approved?Agreed: The TSC approves the release of the Casablanca 3.0.1

Next steps:  Finalize the Release Note & Communicate the Release Readiness.

cl664y@att.com

Amy Zwarico

• Project M1 Review. TSC Recommendations: Approved except Doc/Integration (additional information to be provided) - Project Status in Dublin Release
• M1 Scorecard Review: Dublin Release Requirements
  • Missing insights from integration, docs
  • Recommendation: TSC Approve M1 for Dublin
    • Use cases
      • voLTE NOT committed part of the use case testing
      • vCPE NOT with Tosca - vCPE with Heat
        •  cl664y@att.com Former user (Deleted) split vCPE into two lines
          
      • CCVPN - sub-uses cases not supported - may not meet needs
        •  Davide Cherubini to meet with LIN MENG to review and get final feedback
      • 5G - Not a full commitment by all the PTLs
      •   Benjamin Cheung - review at PTL call on Monday
    • Functional Requirements
      • Consistent ID in cloud region
        •   Bin Yang issue partial use case support
        •  Bin Yang Yang Xu meet to discuss testing
          
      • Distributed Analytics - need to move from func requirements to use case (deliver as POC)
        •  Srinivas Tadepalli Marco Platania Yang Xu work together to identify another repositiory than demo - to be followed on 2/4 on PTL call
        •  Former user (Deleted) create another category on Dublin Release Requirements to capture POC - dark code; no release documentation; cannot hold up release; need to make sure documentation expectations are clear
          
          
      • Change management Dublin extensions
        • Flexible designer - not fully committed, stretch goal (VID still hase concerns)
        •  Ajay Mahimkar & Ryan Hallahan to speak w/ Seshu Kumar Mudiganti regarding scope
      • Self serve control loop - want to keep it in Dublin albeit without sufficient resources (move to POC)
      • Fine-grained placement service - E2E use case integration at risk (move to POC)
      • Modularity - will implement modularity in phases (P1 - SO only)
      • ETSI alignment - SO only
    • Non-functional requirements
      • Container Footprint Environment -

        • S3P Manageability Level 2 Requirement. However, no projects are listing that they will meet Level 2

      • •  Adolfo Perez-Duran will present at PTL meeting -
          
      
      
• M1 Security Checkpoint
• M1 SP3 Checkpoint: https://lists.onap.org/g/onap-tsc/message/4540
  
  • Performance: Several projects involved in closed-loop activities are not proposing to meet level 2.  What is the challenge?
  • Stability:  most all projects are at least level 1… if Integration team does the platform level stability test (as done in past), we should be good
  • Resiliency: good
  • Security: defer to security subcommittee, but there are not enough projects committing to silver level to meet the overall goal of 70% of projects at silver
  • Scalability: good
  • Manageability: very few projects at level 2.  Would like to understand the reasons for not being able to meet level 2.
  • Usability: also very few projects at level 2.  What are the reasons for not being able to meet level 2?
• TSC M1 Approval?
• Next Milestone: M2 Functionality Freeze (2/22) - Release Planning

Amy Zwarico

Paweł Pawlak

Alla.Goldner

cl664y@att.com

cl664y@att.com

Kenny Paul

Michael O'Brien

Attendees:

Kenny Paul
Michael O'Brien
Mike Elliott
Sylvain Desbureaux
Habib Torab
Jun (Nicolas) Hu
@Paul Ionut Vaduva
Alain Soleil
Gary Wu
Jessica Wagantall
Jim Baker
John Lotoski

By request of Dublin Scorecard -

https://lists.onap.org/g/onap-tsc/topic/dublin_m1_scorecard_tsc/29536574?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29536574

Alexis de Talhouët is welcome as TSC management - his deep technical "hands-on" approach will be appreciated

Meeting Minutes: 20190124

Video on CD - Continuous Deployment

• recording - except during sensitive pw screens -
• Bengt Thuree needs another slot - moved to Thu 2030
• 1830 in france not good - 2030 is good - will move meet to 1430EDT
• LF is the level of testing their own deployment
• Orange/OOM discussion in the past - working on pulling the release tag for a gerrit review poc -

around

sudo helm deploy local/onap --namespace onap -f onap/resources/environments/disable-allcharts.yaml --set so.enabled=true

server
https://gitlab.com/Orange-OpenSource/lfn/onap/onap_oom_automatic_installation/pipelines/44398686

• orange oom deploy step: validation steps are kubectl get pods, healthcheck, and some TBD subset of a use case (4 use case VNFs, (IMS,,,,)
  - SO issue being worked on by Sylvain Desbureaux and Morgan Richomme
• source above on https://gitlab.com/Orange-OpenSource/lfn/onap/onap_oom_automatic_installation
• Orange higher level source for all LF projects in https://gitlab.com/Orange-OpenSource/lfn
• Bengt Thuree working with IT/infra team for for VM's -
• next meeting next thu 31st Jan - demo from Orange next thu - 2030 GMT+1 (france time)
• how to work - keep it in the main jira as notes... - LF will work out integration with the infrastructure they are bringing up
  - a status mid week would be beneficial from the LF (you can work in the jira or subtask or via comments on the jira)
• key is getting the magic word working from an oom review - Orange Sylvain Desbureaux can work with Bengt.

• Ultimate Main Goal: prevent to merge code that has not been tested in a CD environment.

•   POCs
  Integration team: 2018
  Gary Wu - full onap system 13 vms - freq: master once a day
  http://onapci.org/grafana/d/8cGRqBOmz/daily-summary?orgId=1
  https://github.com/garyiwu/onap-lab-ci

  Logging/OOM Team: 201710
  Michael O'Brien - partial onap system 1 vm - freq: hourly for 3 pod - 6 hours for full onap deploy 256G vm
  http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS
  http://jenkins.onap.info/job/oom-cd-master2-aws/
  https://git.onap.org/logging-analytics/tree/deploy

  Orange Labs 201901
  https://gitlab.com/Orange-OpenSource/lfn/onap/onap_oom_automatic_installation/pipelines/44398686
  https://gitlab.com/Orange-OpenSource/lfn

• 
  

• Proposed flow 1 should be doable for Dublin - fully automated CI/CD - ElAlto due to VM resources
  - gerrit commit on the oom repo for a particular component like so, aai - keyed by Issue-ID Jira
  - helm-verify jjb jenkins job currently runs - reports +1/-1
  - manual magic word "run-helm-deploy" will kick in a helm-deploy jjb job 
  that deploys robot and the particular pod to a 16-32g VM 
  (preconfigured with rancher as a single node) - how? jenkins will run a 
  remote ssh shell to a server using a cached key - a cd.sh script will 
  need to be written - see the 2 pocs below already running 
  - reports +1/-1 if healthcheck for that component passes after 20 min 
  - parse the logs from jenkins
  - scripts to bring up k8s/helm/docker - see links in comments