...
Consequences for ONAP deployment
We want to move to 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, the link to databases links databases and contrib components will be set in a more clearer way as of than today
- OOM "databases" will be installed optionnallyoptionally. 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 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 will be mandated for ONAP to run 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.
...
- 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 anything is not provided
Consequences on Databases deployments
...
It's again encouraged to use dedicated deployments for your environnmentsproduction environments