<div dir="ltr">It is well-written here in OPNFV artifact:<div><br></div><div><a href="http://artifacts.opnfv.org/availability/review/33475/development_overview/index.html">http://artifacts.opnfv.org/availability/review/33475/development_overview/index.html</a><br></div><div><br></div><div>Br,</div><div><br></div><div>Tuan/Nokia</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 10, 2017 at 3:49 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5/9/2017 1:11 PM, Waines, Greg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am looking for guidance on where to propose some “_VM Heartbeat /<br>
Health-check Monitoring_” functionality that I would like to contribute<br>
to openstack.<br>
<br>
<br>
<br>
Briefly, “_VM Heartbeat / Health-check Monitoring_”<div><div class="h5"><br>
<br>
·         is optionally enabled thru a Nova flavor extra-spec,<br>
<br>
·         is a service that runs on an OpenStack Compute Node,<br>
<br>
·         it sends periodic Heartbeat / Health-check Challenge Requests<br>
to a VM<br>
over a virtio-serial-device setup between the Compute Node and the VM<br>
thru QEMU,<br>
<br>
·         on loss of heartbeat or a failed health check status will<br>
result in fault event, against the VM, being<br>
reported to Vitrage thru its data-source API.<br>
<br>
<br>
<br>
Where should I contribute this functionality ?<br>
<br>
·         put it ALL in Vitrage ... both the monitoring and the<br>
data-source reporting ?<br>
<br>
·         put the monitoring in Nova, and just the data source reporting<br>
in Vitrage ?<br>
<br>
·         other ?<br>
<br>
<br>
<br>
Greg.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
p.s. other info ...<br>
<br>
<br>
<br>
Benefits of “VM Heartbeat / Health-check Monitoring”<br>
<br>
·         monitors health of OS and Applications INSIDE the VM<br>
<br>
o    i.e. even just a simple Ack of the Heartbeat would validate that<br>
the OS is running, IO mechanisms (sockets, etc)<br>
are working and processes are getting scheduled<br>
<br>
·         health-check status reporting can trigger and report on either<br>
high-level or detailed application-specific audits within the VM,<br>
<br>
·         the simple virtio-serial-device interface thru QEMU is UP very<br></div></div>
early in VM life cycle and is virtually _always up_<span class=""><br>
<br>
o    i.e. its available for reporting issues virtually all the time,<br>
<br>
o           ... compared to reporting issues over Tenant Network to a<br>
remote VNFManager which relies on Ethernet and IP Networking within the<br>
VM itself and then any provider network and adjacent routers around the<br>
compute nodes ...<br>
<br>
·         uses a simple “Line-Delimited JSON” Format over virtio serial<br>
device ( <a href="http://www.linux-kvm.org/page/Virtio-serial_API" rel="noreferrer" target="_blank">http://www.linux-kvm.org/page/<wbr>Virtio-serial_API</a> )<br>
<br>
o    simple to implement protocol inside VM, in pretty much any language<br>
<br>
o    ( although would provide reference implementation )<br>
<br>
·         provides more thorough instance monitoring than libvirt’s<br>
emulated hardware watchdog (<br>
<a href="https://libvirt.org/formatdomain.html#elementsWatchdog" rel="noreferrer" target="_blank">https://libvirt.org/formatdoma<wbr>in.html#elementsWatchdog</a> )<br>
<br>
<br>
<br></span>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
How is this different from the watchdog action flavor extra spec / image property which already exists?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div>