Page Comparison

 Linux Foundation

Transfer of "info.yaml" file management at project level, ensuring immediate alignment with the project team composition and Open Source Best practices

<1/21/2019>: PTL agree to take over the ownership of the info.yaml file

cl664y@att.com

Yang Xu

Sofia Wallin

Remaining Open Issues: https://lists.onap.org/g/onap-release/message/992

Integration Status: Casablanca Maintenance Release Integration Testing Status

• 6 Use cases not yet confirmed by the Use Case Owners that they will perform the regression tests - to be followed-up
• Stability issue on WindRiver (SB00) -Stephen Gooch has been triggered. Update: Stephen confirmed compute node 11 reboots itself every other day and caused the issue, and he takes it out today 01/21/19.
• Integration Blockers: Casablanca Maintenance Release Integration Test Blocking Issues

Inter-dependency of some components i.e. DMaaP, CCSDK, etc. can generate some problems. PTLs should send a note if they are updating their version in the Manifest. The Manifest is the true source.

Release Note - Target: January 24th, 2019:

• Please update the Security Vulnerability wiki page if you have updated anything: /wiki/spaces/SV/pages/16090044
• Request to update the latest Readthedoc and then to cherry pick to Casablanca branch
• Do an "Append" so the previous Casablanca content is included but add the Casablanca Maintenance Release tag - 3.0.1 and the date: January 31st, 2019
  

cl664y@att.com

Sofia Wallin

Additional M1 Security Checklist Items approved by TSC on 1/17

Deliverables for Planning Milestone Checklist Template

M1 Milestone Review with TSC: January 24th except Integration, January 31st, 2019

Please complete your M1 Release Plan/Checklist/etc no later than January 23rd, End of your Day 

• Please review your M1 S3P Actual and provide your S3P M1 target: https://wiki.onap.org/display/DW/Dublin+Release+Platform+Maturity
• Please update any risk/issue (if any):  https://wiki.onap.org/display/DW/Dublin+Risks
• Please provide your commitments on the centralized wiki: https://wiki.onap.org/display/DW/Dublin+Release+Requirements

Any concern/question for your M1?

Documentation Plan Proposal - please send feedback to Sofia prior the next TSC call (1/31)

Potential Dublin branch target date: RC1? To be reviewed at that time.

Continue dev.yaml adjustment for ReplicSet: 1

This reduction of 20+ containers is easier - just need a signoff on several PTLs that the remaining clusters actually run with 1 instance enough for dev.

DEV environment deployment footprint reduction by reducing remaining ReplicaSet clusters to 1 from 2/3/5/7 - only in dev.yaml override

OOM-1578 - DEV mode dev.yaml override for all remaining ReplicaSet counts still above 1 In Progress

https://lists.onap.org/g/onap-discuss/topic/running_onap_in_dev_with_all/29018548?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29018548

2 S3P points - conditional dependencies and one found by James MacNider when testing appc healthcheck - explicit init container dependencies required by non-atomic healthchecks

(1)

Discussion on state of enforced dependencies - SDNC and AAI are good examples - for SDNC it will not deploy unless dmaap, consul and sdc are pre-deployed, however other projects that have compile-time/injection-time pom.xml dependencies are not reflected.

Some projects have explicit deployments set in their init containers - others do not yet.

Issues:

Enforced dependencies block a module for dev testing unless dependencies are up

For example - everyone needs AAI up - but there are no init containers referencing AAI so any module can deploy without AAI - but functionality will be limited.

Proposal:

Follow - as usual - AAI example - where they put in a conditional on the --set enabled flag - and don't enforce the dependency - not blocking bringing up just a single module. However if the dependency is enabled in dev/values.yaml then the dependency is checked.

https://git.onap.org/oom/tree/kubernetes/aai/charts/aai-traversal/templates/job.yaml#n42

    spec:      initContainers:
        {{ if eq .Values.global.aafEnabled true }}
        - --container-name
        - aaf-locate
        {{ end }}

The deployment profile is useful for module-level deployments, consistent sequential deployments, CD and dev environments

current state

https://lists.onap.org/g/onap-discuss/topic/oom_sdnc_just_deploy_sdnc/28989874?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28989874

or higher level

LOG-924 - Kubernetes chart dependencies - make all 105 in 87 files conditional - post yaml for cd In Progress

Michael O'Brien

James MacNider

•  Helm Chart Transfer: 4 projects have been identified for trial: Log, Policy, APPC and Clamp. Mike Elliott will work with PTL to gather/transfer knowledge and create training materials. Training to be done the week of Jan 14 and PTL to provide their commitment or not by M1 on Jan 1724.
  <1-7/2019>: Work in progress. Schedule might shift to another week. Michael will follow-up with Mike. Training will be open to everybody. The objective is that each team will take over the management of their Helm Charts.
  
  
•  K8S: Ensure labs are updated to relevant K8S version
  <1-7/2019>: Ongoing. K8s 1.11.5; Rancher 2.0 - parameters set in the Heat template to bring the VMs related to K8S. 
  <01/13/2019> From Integration, here are the related versions:
  

  docker_version:
  type: string
  default: "17.03.2"

  rancher_version:
  type: string
  default: "1.6.25"

  rancher_agent_version:
  type: string
  default: "1.2.11"

  kubectl_version:
  type: string
  default: "1.11.5"

  helm_version:
  type: string
  default: "2.9.1"

  
  k8s scripts here https://git.onap.org/integration/tree/deployment/heat/onap-oom
  and secondary here https://git.onap.org/logging-analytics/tree/deploy  - under https://jira.onap.org/browse/OOM-1496
  https://wiki.onap.org/display/DW/Security+Space+Wiki+Access+List
•  Oom values.yaml or integration repo manifest ( TSC-86 - Lock down docker image tag name source of truth - oom values.yaml or integration repo manifest - A: both but manifest is the source Submitted )

  if not covered - see TSC 2019-01-10

  Quick discussion on nailing down whether we need a yaml override of the deployable

  docker image tags in the oom repo (understanding is no) - with the integration docker manifest

  (manifest is currently a copy of the oom values.yaml tags - not the reverse)

  If not - then we need a documented procedure wiki/RTD on running a derived values.yaml override for the entire system before deployment

  AAF is only an example here

  https://git.onap.org/oom/tree/kubernetes/aaf/charts/aaf-service/values.yaml?h=casablanca#n28

  image: onap/aaf/aaf_service:2.1.8

  drives

  https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv?h=casablanca#n11

  onap/aaf/aaf_service,2.1.8
  
  <1-7/2019> Integration team to document the procedure.

  <01/13/2019> Answer from Integration team: docker manifest under integration repo is the source of truth, and is used by Integration team to override OOM values.yaml when deploying ONAP in Openlab. See the instructions at the bottom of page https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/onap-oom-heat.html#onap-oom-heat-template
  <1-21/2019> Procedure should include Timers, dependencies, etc.
  just need to define all the --set and -f overrides like the following
  sudo helm deploy onap local/onap --namespace $ENVIRON -f $DISABLE_CHARTS_YAML  -f $DEV0_YAML $APPENDABLE_ENABLED_FLAGS --verbose

•  WindRiver Lab Management - Please provide feedback to Stephen Gooch no later than January 31st, 2019 if you need to keep your tenant space, VMs: user-usage.txt