Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

by Sylvain Desbureaux and Krzysztof Opasiak


OOM "matrioshka model"

Consequences for ONAP deployment


We want to move to 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, the link to databases will be set in a more clearer way as of today
  • OOM "databases" will be installed optionnally. 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 test only. It'll be discouraged to use them in production are these charts will be present only to run e2e test cases
  • Platform part will be mandated for ONAP to run (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. 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 everything 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 environnments


  • No labels