[Starlingx-discuss] Fault Management Containerization (SB 2004008) Follow Up

[Arce Moreno, Abraham]

Thanks Frank for setting this up. Thanks everyone for your attendance to this meeting, here you have high level notes and ToDos based in the topics covered.

In Summary

- The presentation Stx-Fault/Containers is located at [0].
- Tao will kindly update the Fault Management architecture diagram, slide 8.
- Mario will send an email no later than Monday afternoon with the latest findings / questions based in his 5 ToDos.
- We will meet again on Tuesday to finalize on tasks and implementation details.

If we are forgetting about any key point in this email, please do not hesitate to reply.

StarlingX Architecture

- 2 instances for each of the following projects:
  - Keystone
  - Horizon
  - Barbican
- Fault Management will have 2 instances as well.

Fault Management Architecture

- [ToDo] [Tao] to modify the Fault Management architecture (Slide 8) Thanks Tao!
- fm-api runs in compute node, snmp provide interfaces
  - [ToDo] [Mario] to check these statements

Fault Management REST API

- [ToDo] [Mario] to write the next level of details for REST API mapping / implementation, consider to include PUT to Event Log.

Fault Management Architecture

- python-fmclient is a wrapper to fm_cli / fm_api
  - [ToDo] [Mario] to understand more about fm_cli as a wrapper and how does it interact and affects fault management containerized strategy.

FM Proposal

- Remove mysql, fm-api, fm-common
  - [ToDo] [Mario] to understand about the removal of fm-api and fm-common from the containerized instance.
- Dependency to cgts-client
  - [ToDo] [Mario] to understand what is cgtc-client and how does it interacts with fault management and the new containerized instance.

OpenStack Applications

The following 2 projects will make use of the Fault Management containerized:
- starlingx-dashboard
- stx-nfv

[0] https://docs.google.com/presentation/d/1_vG83aHTToXlIdJxaJpVL-MHWfRGnxLuyEdFDt-nfwo/edit?usp=sharing