StarlingX/Containerization

Fault Management Sync & Tracking

Objective

• Context.
• Clarify general doubts about StarlingX Architecture.
• Clarify doubts and questions about fm service[s] architecture.
• Clarify the goal for the new architecture of fm service[s] to be containerized.
• Agreement with a plan of tasks and next steps.

Story 2004008 [Feature] Create HELM chart for Fault project

StarlingX Context

• This story will provide the infrastructure to deploy FM service in containers.
• Part One: The current FM service will continue to run on bare metal for the Platform Service.
• Part Two: A second containerized instance will be deployed as part of the Openstack Application for Openstack alarming/events.
• Part Three: The VIM would interface with the containerized instance for generation/clear of openstack alarms/events.
• Is the VIM the short name for nfv-vim? Yes

Summary of key communication exchanged in the last 2 weeks:

StarlingX Context

• Containerized only fm-rest-api
• This includes implementing PUT/POST methods
• And change backend from Postgress to MySQL/MariaDB
• Excluded
• Alarm Suppression
• SNMP
• Maintenance Alarming
• There are 2 instances of Keystone, Horizon and Barbican, this approach must be considered to have 2 instances of Fault Management.
• Database Model

StarlingX Architecture

Platform Services

Flock Services

+

StarlingX Architecture

1. CEPH
2. Keystone ?
3. Postgres
4. Rabbitmq

​

​

1. Configuration management
2. Host management
3. Fault management
4. Software management
5. Service management

​

Story 2004008 [Feature] Create HELM chart for Fault project

Part One: The current FM service will continue to run on bare metal for the Platform Service.

OpenStack Applications

StarlingX Architecture

• aodh
• barbican
• ceilometer
• cinder

​

• glance
• heat
• keystone ?
• nova

Story 2004008 [Feature] Create HELM chart for Fault project

Part Two: A second containerized instance will be deployed as part of the Openstack Application for openstack alarming/events.

Fault Management Architecture

fm-rest-api

fm-api

fm-common

postgress

SNMP

Controller

fm-mgr

18002

8001

oslo

keystone

fm-api

Compute

Fault Management Architecture: fm-rest-api

Part I

stx-fault REST API

​

• Alarms
• Event Log
• Event Suppression

​

• alarm_create
• Available but not used
• Is this the method to map the requested PUT/POST methods?
• alarm_get
• alarm_get_by_id
• alarm_get_all
• alarm_get_list
• alarm_update
• Is this the method to map the requested PUT/POST methods?
• alarm_destroy
• alarm_destroy_by_ids
• event_log_get_all

Mapped to available fm_api methods

Fault Management Architecture: fm-rest-api

Part I

• log_uuid
• None
• event_suppression_uuid
• python-fmclient
• v1/event_suppression_uuid fm-rest-api
• starlingx-dashboard
• API v1/event_suppression_uuid

fm-rest-api

• alarm_uuid
• stx-nfv
• nfv-plugins
• fm_api > fm-api
• nfv_vim
• nfv-common
• nfv-common
• fm.py > fm_api > fm-api
• stx-integ
• monitoring
• fm_api > fm-api
• ceph
• fm_api > fm-api

Who and how fm-api methods are consumed

FM Current

fm-rest-api

fm-api

fm-common

postgress

SNMP

Controller

fm-mgr

18002

8001

oslo

alarm_allowed

stx-nfv

python-fmclient

Compute

ceph

monitoring

python-fmclient

keystone

stx-dashboard

alarm_uuid

event_suppression_uuid

FM Proposal

fm-rest-api

fm-common

fm-api

postgress

SNMP

Controller

fm-mgr

1800X

8001

oslo

alarm_allowed

stx-nfv

python-fmclient

Compute

ceph

monitoring

python-fmclient

keystone

stx-dashboard

fm-common

Pod

fm-api

POST / PUT / GET / DELETE

alarm_uuid

event_suppression_uuid

fm-rest-api

18002

Stx-nfv

Alaria DB

Fault Management Architecture: Questions

• Database
• Current
• Postgress is currently used.

​

• Future
• There is a request to migrate from Postgress to MySQL.
• Are we using the existing OpenStack MariaDB image?

Fault Management Architecture: fm-rest-api

Part II

• Platform Services :: Bare Metal
• distributedcloud
• stx-config controllerconfig
• stx-config backup_restore
• stx-config sysinv
• stx-integ ceph
• stx-integ monitoring
• stx-metal inventory
• stx-nfv
• stx-update patch-alarm
• OpenStack Applications :: Container
• glance
• neutron
• starlingx-dashboard

• distributedcloud
• glance
• neutron
• starlingx-dashboard
• stx-config controllerconfig
• stx-config backup_restore
• stx-config sysinv
• stx-integ ceph
• stx-integ monitoring
• stx-metal inventory
• stx-nfv
• stx-update patch-alarm

fm_api.Fault called from stx projects

and how to map into the split of Platform and OpenStack Applications

Current :: Bare Metal

Proposal

Plan :: Requirements

• Wheel Packages
• Task 29400 Missing wheel packages (pecan and wsme) Merged
• Docker Image
• Task 28874 Create Docker images for the FM service
• Add fm-rest-api docker image directives files https://review.openstack.org/#/c/634540/
• Chart
• Task 26955 [Feature] Create HELM chart for Fault project
• Add chart to deploy fm rest api https://review.openstack.org/#/c/637120/
• Tar Gzip
• Task 29987 Produce fm-rest-api tgz file
• Produce the fm-rest-api tgz file https://review.openstack.org/#/c/642798/

Plan :: Requirements

• Database (Changes in Chart and OSLO)
• Tasks 0000 Add MySQL database into the pod where fm-rest-api is Take a look at others
• Tasks 0000 Change the backend for fm-rest-api from Postgress to MySQL
• REST API (Changes in fm-rest-api directory, stx-fault project)
• Tasks 0000 Implement for fm-rest-api missing REST API methods: PUT / POST
• Python FM Client
• Task 0000 Add calls from python-fmclient to fm-manager
• OpenStack Applications
• Horizon (Changes in starlingx-dashboard project)
• 28878 Horizon would point to the containerized FM API
• 28877 Integrate FM panel into the containerized horizon instance along with alarm banner
• Stx-nfv
• 28876 Modify the VIM to interface to the containerized FM api for openstack alarms/events

Plan :: Deployment

• Armada
• [WIP] Add fm-rest-api chart to armada system https://review.openstack.org/#/c/642925/

Thanks!