Istanbul intents

by @Sylvain Desbureaux, @Krzysztof Opasiak and @Vijay Kumar

keep going on High Level vision for OOM

Helm / Kubernetes support

Goal is to support (almost) latest versions:

• Helm 3.6

• Kubernetes 1.21 or 1.20

  • It seems we have issue with mariadb here

Dual stack

Dual Stack in Kubernetes is moving to beta

Change our templates to follow new configuration

Internal Helm registry

Dependent REQ for Istanbul

REQ-685 - DCAE Transformation to support Helm (Phase2) - DCAE Cloudify platform provided local inventory where are all MS deployment artifacts (blueprints) were stored and served through REST api for on-demand deployment (from CLAMP, Dashboard, Robot etc). With DCAE architecture transformation to Helm, Cloudify and related handler will be deprecated.

REQ-716 - Control Loop in TOSCA LCM

ONAP Registry Solution

Primary Usecase

Access within ONAP cluster to retrieve Microservice artifacts (helm charts) provided under ONAP release

• Nexus3 can address this requirement; currently WIP to release ONAP charts. This solution introduces some overhead for ONAP offline requirement.

Dynamic MS onboarding/upload of helm charts

• Requires REST endpoint support for charts to be pushed into repository which will be retrieved by other ONAP components.

• Nexus3 repo is not an option here as PUSH is supported only through ONAP LF CI.

Istanbul Solution

ChartMuseum will be deployed as ONAP platform component and serve as Helmchart repository server hosting required ONAP component charts within Cluster.

• Accessible only as ClusterIp service

• Basic Authentication enabled

Chart Location - oom\kubernetes\platform\components\chartmuseum (https://gerrit.onap.org/r/c/oom/+/121693)

Solutions evaluated for registry initialization

Preload via configmap

Cons: Size constraint to host all required chart

Handle via job

Chartmuseum-init will include script and use kubectl proxy to preload

Pros:

• Follows current process/tooling used in ONAP deployment

Cons:

• Not completely cloudnative and need new script be invoked part of gating/day0 OOM setup prior to Integration/gating executions

Docker container

Prepackage all charts required into a container

Pros:

• Repo initialization handled part of post install of Chartmuseum deploy; cloud-native

Cons:

• Add overhead in container management/release without automation in place.

• Require chart to be released;

  • new container snapshot build,

  • release yaml submission/approval

  • and then OOM patch

K8s Operator with chartmuseum

Cons:

• Charts not maintained and required further work to support helm3 and meet OOM standard

Chosen solution for Istanbul: Handle via job

Service Mesh

Accelerate on Service Mesh PoC

See https://wiki.lfnetworking.org/display/LN/2021-06-08+-+ONAP%3A+Next+Generation+Security+and+Logging+Architecture%2C+Design+and+Roadmap for complete presentation

Ongoing work:

• Script to configure keycloak

• Script to install cert manager, keycloak, istio on a kubernetes cluster (for testing purpose)

• Service Account creation

• Configuration of components (DMaaP, AAI, SDC, SO, SDNC) to support being on service mesh

Version bumps

continue bumping versions of different "common" components:

• mariadb

• cassandra

• postgresql

• etcd

• elasticsearch

• consul

• ...

Automated certificates retrieval

finish the work on remaining certificates:

• AAI babel

• AAI sparky be

• AAI schema service

• ESR server

• multicloud fcaps / starlingx

• robot

• uui

Externalize Databases

Internship started to see what is the work to externalize one Database instance into another namespace

Prometheus metrics exposure

create template to simplify add of these metric exposure

add a generic template for java spring boot components