General

1. What does POMBA stand for?

   1. Post Orchestration Model Based Audit

2. What does the report look like?
   1. See POMBA Reporting
3. How is POMBA triggered?
   1. Currently, it is triggered via a REST call. In the future, it may also be triggered via an end of orchestration event from SO. 
4. Does the POMBA Common Model align to the ONAP Common Model?
   1. 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.
5. Is POMBA meant to find software bugs in ONAP?
   1. 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).
6. Do you support validation against operational policies?
   1. 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.
7. How does POMBA know the values it is auditing are correct?
   1. It doesn't unless you encode that in the rules. By default, POMBA compares different definitions of the resource and reports anomalies.
8. Why wouldn't I just run some traffic on the service to prove it works?
   1. That is a different test.  A service may be incorrectly instantiated and still carry traffic or be correctly instantiated and not carry traffic.
9. How do the various components of the solution talk to each other?
   1. 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.
   2. See also
      1. POMBA Audit Initiation Swagger
      2. POMBA Context Builder Swagger
      3. Network Discovery API Swagger
      4. Integration with Data Dictionary

Context Builders

1. What is a Context Builder?
   1. It is an independent Microservice capable of getting information about a service or service instance from a particular data sources (SDC, SDN-C, A&AI, Network). They each support the same API. See POMBA Context Builders and Data Sources for more information.  This allows POMBA to easily compare the data and generate a report.
2. How many Context Builders are there?
   1. One for each source of data - SDC, SDN-C, A&AI, Network, etc.
   2. Conceptually, the SDC one is defining a type of service while the others are dealing with service instances.
3. If I want to add a new source of data, then I need a new Context Builder?
   1. Yes. Note in some cases extending the network discovery feature may also be an appropriate approach, depending on the data source.

Network Discovery Context Builder

1. What do you mean by Network Discovery? Do you really mean Cloud Resources?
   1. Network Discovery may not be the best term, but the idea is to discovery virtual and physical resources involved in providing services in ONAP, as well as their supporting resources.  This will include VNF, VM, physical servers, network both within and between data centres, etc.
2. Does the POMBA Network Discovery Context Builder support Multi-VIM?
   1. When the appropriate APIs are available in Multi-VIM, then yes POMBA should support them.
3. How extensible is the network discovery? How do I support discovering new information or new data sources?
   1. At the moment, adding new attributes and resources is not to bad, but adding a new data source (from a physical device) for example, would be a bit more work.
   2. Longer term, work could be done to make extensibility easier.
4. Can I use Network Discovery without POMBA?
   1. Yes, you could call the Network Discovery Context Builder API directory, or call the underlying Network Discovery API (Network Discovery API Swagger)

Administrivia

1. Where in ONAP is the POMBA working being done?
   1. The bulk of the work will be done in the Logging project.  The architecture committee has Oked this and the scope change is now in front of the TSC for voting. 
   2. Supporting pieces will also be delivered in SDNC and A&AI (still to be discussed with the A&AI working group).
2. Is Logging really the best fit for all parts of POMBA?
   1. We need to be able to move forward and make progress somewhere and it is a good enough fit. In the long term, we may want to consider moving additional parts to other projects if it makes sense. For example 
      
      1. Context Builders moved to be closer to the data they are accessing,
      2. Common third-party tools moved to common place