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 Venkatesh 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 - Getting issue details... STATUS

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



Page viewed times