Open Stack

Yep :-)  That's pretty much exactly what I was suggesting elsewhere in
this thread:

http://lists.openstack.org/pipermail/openstack-dev/2017-May/116748.html

Waines, Greg <Greg.Waines at windriver.com> wrote:
>Excellent.
>Yeah I just watched your Boston Summit presentation and noticed, at least when you were talking about host-monitoring, you were looking at having alternative backends for reporting e.g. to masakari-api or to mistral or ... to Vitrage :)
>
>Greg.
>
>From: Adam Spiers <aspiers at suse.com>
>Reply-To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>
>Date: Tuesday, May 16, 2017 at 7:42 PM
>To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>
>Subject: Re: [openstack-dev] [vitrage] [nova] [HA] VM Heartbeat / Healthcheck Monitoring
>
>Waines, Greg <Greg.Waines at windriver.com<mailto: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 :)
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev