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.wai...@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 <aspi...@suse.com> Reply-To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Date: Tuesday, May 16, 2017 at 7:42 PM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [vitrage] [nova] [HA] VM Heartbeat / Healthcheck Monitoring Waines, Greg <greg.wai...@windriver.com<mailto:greg.wai...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev