Open Stack

Waines, Greg <Greg.Waines at windriver.com> wrote:
>Sam,
>
>Two other more higher-level points I wanted to discuss with you about Masaraki.
>
>
>First,
>so I notice that you are doing both monitoring, auto-recovery and even host maintenance
>type functionality as part of the Masaraki architecture.
>
>are you open to some configurability (enabling/disabling) of these capabilities ?

I can't speak for Sampath or the Masakari developers, but the monitors
are standalone components.  Currently they can only send notifications
in a format which the masakari-api service can understand, but I guess
it wouldn't be hard to extend them to send notifications in other
formats if that made sense.

>e.g. OPNFV guys would NOT want auto-recovery, they would prefer that fault events
>                      get reported to Vitrage ... and eventually filter up to Aodh Alarms that get
>                      received by VNFManagers which would be responsible for the recovery.
>
>e.g. some deployers of openstack might want to disable parts or all of your monitoring,
>         if using other mechanisms such as Zabbix or Nagios for the host monitoring (say)

Yes, exactly!  This kind of configurability and flexibility which
would allow each cloud architect to choose which monitoring / alerting
/ recovery components suit their requirements best in a "mix'n'match"
fashion, is exactly what we are aiming for with our modular approach
to the design of compute plane HA.  If the various monitoring
components adopt a driver-based approach to alerting and/or the
ability to alert via a lowest common denominator format such as simple
HTTP POST of JSON blobs, then it should be possible for each cloud
deployer to integrate the monitors with whichever reporting dashboards
/ recovery workflow controllers best satisfy their requirements.

>Second, are you open to configurably having fault events reported to
>Vitrage ?

Again I can't speak on behalf of the Masakari project, but this sounds
like a great idea to me :)