2021-05-27 DCAE OOM Meeting

Bridge

[dcaegen2] Team ONAP11, Wed UTC 13:00 (9 AM EDT)

ONAP Meeting 11 is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/98967242523?pwd=YmhlbGZGU0NjcFBnbDdCS3c1Nnk3UT09

Meeting ID: 989 6724 2523
Passcode: 899004

One tap mobile
+13126266799,,98967242523# US (Chicago)
+16465588656,,98967242523# US (New York)
Dial by your location
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
Meeting ID: 989 6724 2523
Find your local number: https://zoom.us/u/ad1U59khic?

ACTION REQUIRED BY ALL COMMUNITY MEMBERS

All attendees must set their Zoom name in First-name FAMILY-NAME (company) format
WAITING ROOM ENABLED by default; HOST/CO-HOST will allow attendees following naming convention.

Recording:

DCAE_OOM_meeting_05272021.mp4

Attendees:

Vijay Kumar Krzysztof Kuzmicki Krzysztof Opasiak Sylvain Desbureaux Jack Lucas Ajay Deep Singh

Discussion Topics:

One of meeting to discuss HELM registry design/solution within ONAP

ONAP-HelmRegistrySupport_v1.0.pptx

Open items:

SECCOM: Authentication choice between Basic Auth Bearer/Token Auth HTTPS(with certificates)
- Authentication - HTTPS.Basicauth for Istanbul; explore HTTPS/cert for future
- Fine grained authorization for Helm registry API's??
OOM: Placeholder repo under OOM(oom/kubernetes/common/chartMuseum)
- Preference of using charts as-is or custom charts using docker container
DCAE: Service Application helm charts should be independently installed using “helm install” command
How Service Applications helm charts will be loaded to chartMuseum:
- Chart museum will connect to helm repo on RKE/Nexus (depending on installation) and download list of required charts.
- Extending access outside cluster via Nodeport temporarily(for initial load)
- Any other proposal ?

OOM team comments from 05/26 meeting:

Remove RKE references from presentation
Consider using PUSH based approach from external/helm registry to avoid FW/security constraint and keeping all flows unidirectional

Comments/discsussion 05/27/2021

Determine need for registry

Usecase 1 - MS provided by ONAP (static)
- Charts packages are released/available and must be preloaded into registry part of Day0
- Integration/CLAMP will require static charts access to deploy on-demand/test flows

Usecase 2 - Support dynamic MS onboarding/upload of helm charts (e.g Acumos flow)
- Ms are not part of ONAP (private components onboarded per ONAP operator)

Usecase2 requires registry support within ONAP (same or different namespace TBD)

Determine how registry should be initalized

How Service Applications helm charts will be loaded to chartMuseum:
- Chart museum will connect to helm repo on RKE/Nexus (depending on installation) and download list of required charts.
- Extending access outside cluster via Nodeport temporarily(for initial load)
- Any other proposal ?
  - Option 1 (PULL)- ChartMuseum (within cluster) will pull required charts part of install based on repo/config list provided; has dependency on nexus3 chart/release build out. Repo list can be nexus3 or repo cloned from ONAP/nexus3 part of offline support.
    - Security risk, certificate management etc to be considered
  - Option 2 (PUSH) - Use k8s api to provide required artifact within cluster (binding to push mechanism); all artifacts are made available upfront.
    - Reproducible

Consensus on option#2

Explore options#2 solutions

Preload via configMap
- size constraint
Using script to preload charts
Handle via job (calls script or kubectl cp)
1. chart 1- chartmusuem
2. chartmuesum-init will include script (machine having access to cluster/chartmuseum registry)
  1. use kubectl proxy
3. Cons: Not completely cloudnative
4. Cons: need to be included part of gating/day0 OOM setup prior to Integration/gating executions
Docker container
1. include all charts required part of initial load
2. Automate docker creation/release and oom update can also be automated; need LF support
  1. Automate release
  2. Automate OOM updates
3. ~~Cons: Soluton not work if component charts are separated to individual repo~~
4. Similar to oom/readiness (https://gerrit.onap.org/r/gitweb?p=oom/readiness.git;a=tree;h=refs/heads/master;hb=refs/heads/master)
K8s Operator with chartmuseum
1. https://github.com/vtuson/chartmuseum-chart/tree/master/templates

Consensus on #3 or #4; finalize target for Istanbul in 1-2 weeks.

Target Repository/placeholder

Charts for ChartMuseum - oom/kubernetes/platform - Components should be able to use onap/chartmuseum or external instance based on configuration in values.yaml

Option#3 scripts → oom/kubernetes/contrib/tools

There were errors rendering macro:

An unknown error occurred.