Just an FYI ... wrt Progress on HA Guest APIs work ... Over the last week or so I have had some discussions on the [openstack-dev] [vitrage] [nova] mailing list, discussing VM Heartbeat / Health-check Monitoring. · had the typical discussions of how it is this different than QEMU libvirt watchdog, · had good suggestion to leverage the QEMU Guest Agent for the low level transport, o https://wiki.libvirt.org/page/Qemu_guest_agent o which sets up the virtio serial device in QEMU and defines the basic transport layer for messaging between the host and guest, and o already has a NOVA flavor extraspec to enable this !
· I suggested that I not put this functionality in NOVA o since, at least implementation-wise, it is not coupled with NOVA, i.e. I would have no NOVA changes now o NOVA doesn’t currently incorporate a lot of monitoring functionality, o AND personally I think it would be a much harder road to get the blueprint accepted in NOVA · I DID suggest that it be put in Vitrage o BUT (rightly) the Vitrage guys indicated that it was NOT really a fit for Vitrage, as Vitrage actually does no ‘monitoring’ itself ... it just provides ‘datasource apis’ for external monitoring mechanisms, like Zabbix or Nagios or CollectD or ... • the Vitrage guys suggested contributing to Zabbix or Nagios • personally, would rather contribute directly to either openstack or opnfv project, rather than to Zabbix or Nagios · HOWEVER I did get interest from a couple of project leads from Masakari o Masakari == HA for VMs o https://wiki.openstack.org/wiki/Masakari o https://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html o they are NOT under BIG TENT right now, but are submitting for this this year o they do • host, process and instance monitoring, and • internal auto-recovery of VMs <-- I realize this is contrary to OPNFV / MANO philosophy, but it is OPTIONAL/CONFIGURABLE o they are introducing alternate reporting APIs on the backend of the monitoring functions • e.g. their default is to the internal Masakari API which then drives their auto-recovery engine • they are integrating with reporting monitoring results to Mistral, and • they seem open to integrating with reporting monitoring results to Vitrage o they seem interested in the VM Heartbeat / Health-check Monitoring • they only do black-box / non-intrusive type instance monitoring today • agree that this would expand their scope • but see value in it o They were willing to accept a blueprint on VM HB/HC Monitoring · I have submitted the blueprint and spec file to the Masakari Launchpad: Blueprint: https://blueprints.launchpad.net/masakari/+spec/intrusive-instance-monitoring Spec: https://review.openstack.org/#/c/469070/ Greg.
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
