Page Comparison

cl664y@att.com

djhunt

Stephen terrill Linda Horn

cl664y@att.com

•  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 17.
  <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: Yang Xu 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

Gary Wu

Yang Xu

cl664y@att.com

Yang Xu

Please review the Windriver information sent by Stephen Gooch

Rules:

• Tenant Space, VM not used over the last 3 months will be deleted.
• People not log over the last 6 months will be deleted

Lab Strategy to be established

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

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

Michael O'Brien

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

Former user (Deleted)