by Sylvain Desbureaux and Krzysztof Opasiak

OOM "matrioshka model"

Consequences for ONAP deployment

We want to move from a monolithic, "install all in same place" installer to a more fine grained installer:

• OOM "core" is always installed. It will be configurable as today (components / subcomponents)
  • of course, links databases and contrib components will be set in a more clearer way than today
• OOM "databases" will be installed optionally. the installations charts will try to be as good as possible for a production deployment but should be taken as "good enough" and not "state of the art" deployments.
• OOM "contrib" are charts meant for tests only. It'll be discouraged to use them in production are these charts will be present only to run e2e test cases
• Platform part are K8s platform components/extensions mandated by ONAP (i.e istio, keycloak operator, cert-manager etc) (some always, some only in certain cases)
  • "all in one" installation will be provided for test, but are not meant to be used in production

As such, "oom deploy" script will deploy only "oom core" part expecting links to all databses and contrib components to be provided explicitly in the override file. For our "test" deployment we'll generate such an override automatically.

The other part will be installed using normal "helm install" and will have to be done before.

A script to transfer needed secrets from one part to another will also be provided.

Consequences for Component deployments

• The database(s) needed for each core deployments may not be provided by ONAP:
  • Thus, we need to give a range of version (and a prefferred one)
  • We also need to give what to be created by external system (users, table) as we may not have admin access
  • We also need to be able to configure simply database access / credentials for deployment
• Mandated platform / external components must be stated clearly and deployment should fail before start if anything is not provided

Consequences on Databases deployments

• Our deployments must not be "ONAP only" (but can be "ONAP centric")
  • maybe we'll move to "standard" charts in a future (to be discussed)
• we'll try to make them as good as possible but use of "expert installed" deployments is encouraged

Consequences on contribution deployments

• Our deployments must not be "ONAP only" (but can be "ONAP centric")
  • maybe we'll move to "standard" charts in a future (to be discussed)
• they'll continue to be "good enough" for use cases testing but not be testing for "lasting long"

Platform deployments

An ansible script (used in our dailies / gating deployments) will be provided as is.  It's meant to be as good as possible for the use cases we know.

It's again encouraged to use dedicated deployments for your production environments