Gating is now a must have to ensure the stability of the release

A 2 steps process has been suggested to simplify integration work and avoid dealing with unsync manifest/branch when testing the OOM deployment (melliott).

In Dublin all the gating has been performed on Orange infrastructure (up to 4 simultaneous full ONAP) , which consists then a de facto point of failure for the gating. ONAP TSC voted to grant cloud capabilities to offload the gating in the cloud and have at least 2 environment of execution.

Moreover the extension of this mechanism to components (not only the installation) would be helpful to detect regressions prior to docker generation and save integration and troubleshooting time;

A first PoC has been performed by sdesbure (on Orange labs) and ChrisC (on Azure).

The goal of this epic is

• Extend OOM gating by testing cloud offloading (sdesbure, ChrisC)
• See how it can be applied to LFN KaaS when ready (agrimberg)
• Complete SO gating (seshukm)
• Optimize component gating (customized ONAP, just rebuild what is necessary, undeploy/redeploy the new helm charts)
• Converge on temp docker building and helm chart generation from the different initiatives dealing with bots involved in CI (sdesbure, ChrisC, jwagantall)
• Share best practices and document the process if any partner would like to offer gating capabilities and define a voting bot
• Test gating with external/API (AdrianSlavkovsky) or other components if enough resources