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

Compare with Current View Page History

« Previous Version 5 Next »

Here we can check and give feedback to findings of OOM users.

CI/CD for open source SMO

Louis Li (louis li <louis890404@gmail.com>) prepared slides about his findings and experience with the OOM deployment stored here:

Contributions - SMO - Confluence (o-ran-sc.org)

https://wiki.o-ran-sc.org/download/attachments/35881444/2024-1-10%20OSC%20IT-DEP%20SMO%20Deployment%20Upgrade.pdf?api=v2

Facts:

  • it/dep project uses helm charts from the ONAP OOM project
    • By including onap_oom as a git submodule in it/dep code base
  • The latest update for submodule onap_oom was in Nov 2022
    • With ONAP Jakarta release (released in June 2022)

Q&A

  • Page 2: "Problem: Has ONAP Montreal finished its release cycle?"
    • yes, sign-off at 14.12.2023
  • Page 3: "By default, the message router no longer exposes NodePort We expose this port for testing"

    • Could be also exposed via ingress by enabling it in values.yaml of DMAAP:

      message-router:
  ingress:
    enabled: true
    service:
      - baseaddr: "dmaap-mr-api"
        name: "message-router"
        port: *svc_port
    config:
      ssl: "redirect"
  • Page 3: "Upgrades strimzi-operator from 0.28.0 to 0.36.1, Add podAntiAffinity to avoid deploying replica pods on the same node, We change strimzi replica count in helm override from 3 to 1 for single
    node Kubernetes"
  • Page 5: "Does ONAP Plan to Deprecate DMaaP MR?"
    • Yes, initially this was planned in London, but not implemented by all components (Policy, SDNC, DCAE,...)
    • Plans:
      • Policy: POLICY-4402 - Getting issue details... STATUS
      • DCAE (some components) by DT
      • AAI
    • Still (in NewDelhi) missing component support:
    • Planned updates:
      • AAI
      • SO
      • Policy
      • some DCAE components

Fixes/Improvements

  • Page 7: DMaaP mediator listens to MR topics
    • To be checked
  • Page 8: Move configurations to Values file
    • Would gain more flexibility, but also much additional text in values.yaml
    • Possibly only certain variable fields could be exposed
  • Page 9/10: No reusable nonrtric-common chart / Common Templates
    • good idea, also done in ONAP
    • but adds dependency
  • Page 11: Remove nested chart variables
    • Or use "global.xxx" variables
  • Page 12: YAML File Comparison
    • use "helm/k8s recommended labels" → absolutely correct
    • but allow to add own labels (e.g. "app", "version",...) in each chart or globally, as e.g. Istio, ArgoCD,... required special ones
  • Page 13: Values File Changes
  • No labels