Page Comparison

...

1. CI-CD: tools and processes
   1. Self-commit:
      1. automate Docker release version
      2. When time is critical (after RC0), allow PTLs to merge their change. This should allow be applicable to LF IT (CI-Management). 
      3. Option: Follow OpenStack process loosely, I.E. no one merges code except Jenkins. When a Gerrit patch gets at least a +2 from a committer and a +1 from someone else we could have Jenkins merge the patch or do some variation of this to ensure faster patch merges but still ensure code review.
   2. Increase CI-Management committers list
   3. CD: use of OPNFV Clover. Helen/Integration
   4. Packaging: Improve Docker images build: incremental versus rebuild everything, optimize docker package (size, time to download) (LF+Gary-Michael). Fact: 13 docker templates in Beijing. Focus first on the most downloaded docker images (sdc, so aai,...)
   5. Standardize the build jobs (benefit: ease to add dependency): LF.
   6. Daily Build: get back to daily build. Build only image on code changes. (once a week one full build).
   7. Partner with OPNFV: Clover project.
2. Testing
   1. Improve time to get the full ONAP installed and started (currently 12 hours to debug): 1 hour for HC + 1 another hour for instantiate => 3 hours. Every project team effort. Better knowledge (training) of OOM + K8S + Helm
   2. Look at how to architect for testability, and debugability : Brian
      1. the idea is how could we modify the helm chart setup so that we can enable a project to pull a new merge or verify docker without the risk that they will lead to a broken helm install from failed terminatinig pods, pv,pvc, port conflicts etc. 
      2. helm upgrade --set enabled=true/false has led to broken installs and the need to purge
      3. Would be nice to be able to have projects in testing labs segmented so that project A's  make project/make onap; docker stop/enabled=false/enabled=true  doesnt cause other projects to be affected
      4. Right now the teams use HEAT base for preliminary testing because that isolation maintains a more stable debugging environment particulary since developers dont run into the read only file system issues for various configuration files
      5. While it is not the right solution - in some sense the Amsterdam per project namespace was actually more forgiving - although in fairness we didnt use the Amsterdam OOM as much as we did the Beijing OOM 
   3. Love to plug a vFW-vDNS automated testing in the verify jobs: Not realistic for Casablanca. ( Gary to try)
   4. Manual way to build docker off on Verify job
3. Release milestones
   1. Enforcement (respect and act upon automated results): (naming and shaming if criteria not met) on TLabs starting at M2 for Casablanca.(increase lab coverage over time, over release)
      1. HealthCheck: must not be broken for more than 48 hours
      2. Use case (VFW vDNS are automated): must not be broken for more than 48 hours
      3. CSIT: must not be broken for more than 48 hours
      4. Daily Build: must not be broken for more than 48 hours
      5. What for new projects?: HealthCheck after M4
      6. Perform testing Staging and Prod env: Gary.
4. Labs and Infrastructure
   1. Resource (hardware): Get data from Stephen Gooch : Michael 

      Jira Legacy
      server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key OPENLABS-291

      . WindRiver current  config: 500 VMs, 2.8 TB RAM, 9.8TB Disk. 
   2. Increase uplink speed on windriver network (slicing 10 GB): 
   3. jenkins + nexus (currently 8GB is minimum): make it faster: LF. Jenkins fails cost minimum 1/2 days (for US). To bring this to the TSC→G Board.
5. Packaging
   1. : 
6. Code Coverage and License scan
7. Security
8. SLA with LF: Idea Use JIRA to prioritize tasks.

...