...
- What does POMBA stand for?
Post Orchestration Model Based Audit
- What does the report look like?
- See POMBA Reporting
- How is POMBA triggered?
- In CasablancaCurrently, it will be is triggered as a result of an end of transaction event being emitted by SO. In addition, it some cases it can manually be triggered from VIM.via a REST call. In the future, it may also be triggered via an end of orchestration event from SO.
- Does the POMBA Common Model align to the ONAP Common Model?
- We plan to support the ONAP Common Model. The current POMBA Common Model may have some slight differences, but the API is versioned so this will allow us to seamlessly transition to the ONAP Common Model when appropriate.
- Is POMBA meant to find software bugs in ONAP?
- While that is one of the use cases, it is not the only one. It can also detect if resources outside of ONAP are not behaving as expected, as well as detect changes in services over time that differ from original expectations (with appropriate triggers).
- Do you support validation against operational policies?
- If these policies are modeled in SDC, then we can audit against them. We also have a proof of concept integration to a data dictionary. Currently we don't support additional operational policy definitions but this could be evaluated.
- How does POMBA know the values it is auditing are correct?
- It doesn't unless you encode that in the rules. By default, POMBA compares different definitions of the resource and reports anomalies.
- Why wouldn't I just run some traffic on the service to prove it works?
- That is a different test. A service may be incorrectly instantiated and still carry traffic or be correctly instantiated and not carry traffic.
- How do the various components of the solution talk to each other?
- They are independent Microservices with well defined REST API. They communicate with each other via REST, although some parts of the solution allow for publishing events over MSB/DMaaP for other components to consume.
- See also
...