2021-05-27 DCAE OOM Meeting

Bridge

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

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 off meeting to discuss HELM registry design/solution within ONAP - OOM-2734: Support for Helm registry within ONAP Closed

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

  1. Preload via configMap

    • size constraint

  2. Using script to preload charts

  3. 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

  4. 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)

  5. 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