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> 

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 
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 

o   Masakari == HA for VMs

o    <https://wiki.openstack.org/wiki/Masakari> 


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 
Spec: https://review.openstack.org/#/c/469070/






opnfv-tech-discuss mailing list

Reply via email to