Hi, all. I send this email to check on the progress and see what we can achieve for the E release.
@Greg. How about the progress of the API work. Since the E release MS is approaching, I wonder what we can achieve for this release based on the progress we now have? Whether integration using compass is possible now? @Kanglin & Qiujuan, how about the test case development work? I recall we had some discussion during the summit and you mentioned you are working on the HA test cases and have some plan for the E release. How is the progress? Thank you! 发件人: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] 代表 Waines, Greg 发送时间: 2017年6月1日 20:38 收件人: opnfv-tech-discuss@lists.opnfv.org 主题: [opnfv-tech-discuss] [ha][availability] Progress on HA Guest APIs work 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> 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> https://wiki.openstack.org/wiki/Masakari o <https://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html> 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 opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
