<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Great Idea. I have seen this request coming from multiple folks. </div>
<div><br>
</div>
<div>Especially to detect key events through Zaqar and pass it on to the application, which can then take app specific action.</div>
<div><br>
</div>
<div>Thanks</div>
<div>Vinod. </div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><Fox>, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, May 12, 2015 at 12:51 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments<br>
</div>
<div><br>
</div>
<div>
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
<div>
<div>Hooking it into Zaqar would be awesome too. Once you can trigger Mistral workflows based on Zaqar messages, just imagine the possibilities...<br>
<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Steven Dake (stdake)<br>
<b>Sent:</b> Tuesday, May 12, 2015 12:02:59 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Kevin,<br>
<br>
This is a great idea that would make a solid extension to the software.<br>
If I read the wiki page correctly, the real goal is for operators and<br>
tenants to be able to be notified via querying the ReST API so they could<br>
write their own email/pager-duty app.<br>
<br>
Regards<br>
-steve<br>
<br>
On 5/12/15, 11:16 AM, "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
<br>
>Nagios/watever As A Service would actually be very useful I think.<br>
><br>
>Setting up a monitoring server is a fair amount of work. If "Cloud Apps"<br>
>downloaded from an OpenStack Catalog had a Monitoring Heat resource built<br>
>in, that would register the launched app with a multitenant aware Cloud<br>
>Monitoring Service, the user would only have to launch an app, and then<br>
>go into the Dashboard and associate some kind of alerting policy with the<br>
>registered checks. Say, email this address when things break. That would<br>
>be awesome. :)<br>
><br>
>Thanks,<br>
>Kevin<br>
>________________________________________<br>
>From: Jay Pipes [<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
>Sent: Tuesday, May 12, 2015 10:48 AM<br>
>To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>Subject: Re: [openstack-dev] [new][cloudpulse] Announcing a project to<br>
>HealthCheck OpenStack deployments<br>
><br>
>For operators:<br>
><br>
>* Nagios<br>
>* Icinga<br>
>* Zabbix<br>
><br>
>installed on baremetal machines deployed with the OpenStack and other<br>
>infrastructure services.<br>
><br>
>For tenants:<br>
><br>
>* Nagios<br>
>* Icinga<br>
>* Zabbix<br>
><br>
>installed on their VMs.<br>
><br>
>Why are we re-inventing excellent open-source implementations of<br>
>monitoring systems that have been around for over a decade?<br>
><br>
>Best,<br>
>-jay<br>
><br>
>p.s. Sorry for top-posting.<br>
><br>
>On 05/12/2015 01:20 PM, Vinod Pandarinathan (vpandari) wrote:<br>
>> Hello,<br>
>><br>
>> I'm pleased to announce the development of a new project called<br>
>> CloudPulse. CloudPulse provides Openstack<br>
>> health-checking services to both operators, tenants, and applications.<br>
>> This project will begin as<br>
>> a StackForge project based upon an empty cookiecutter[1] repo. The<br>
>> repos to work in are:<br>
>> Server: <a href="https://github.com/stackforge/cloudpulse">https://github.com/stackforge/cloudpulse</a><br>
>> Client: <a href="https://github.com/stackforge/python-cloudpulseclient">https://github.com/stackforge/python-cloudpulseclient</a><br>
>><br>
>> Please join us via iRC on #openstack-cloudpulse on freenode.<br>
>><br>
>> I am holding a doodle poll to select times for our first meeting the<br>
>> week after summit. This doodle poll will close May 24th and meeting<br>
>> times will be announced on the mailing list at that time. At our first<br>
>> IRC meeting,<br>
>> we will draft additional core team members, so if your interested in<br>
>> joining a fresh new development effort, please attend our first meeting.<br>
>> Please take a moment if your interested in CloudPulse to fill out the<br>
>> doodle poll here:<br>
>><br>
>> <a href="https://doodle.com/kcpvzy8kfrxe6rvb">https://doodle.com/kcpvzy8kfrxe6rvb</a><br>
>><br>
>> The initial core team is composed of<br>
>> Ajay Kalambur,<br>
>> Behzad Dastur, Ian Wells, Pradeep chandrasekhar, Steven DakeandVinod<br>
>> Pandarinathan.<br>
>> I expect more members to join during our initial meeting.<br>
>><br>
>> A little bit about CloudPulse:<br>
>> Cloud operators need notification of OpenStack failures before a<br>
>> customer reports the failure. Cloud operators can then take timely<br>
>> corrective actions with minimal disruption to applications. Many cloud<br>
>> applications, including<br>
>> those I am interested in (NFV) have very stringent service level<br>
>> agreements. Loss of service can trigger contractual<br>
>> costs associated with the service. Application high availability<br>
>> requires an operational OpenStack Cloud, and the reality<br>
>> is that occascionally OpenStack clouds fail in some mysterious ways.<br>
>> This project intends to identify when those failures<br>
>> occur so corrective actions may be taken by operators, tenants, and the<br>
>> applications themselves.<br>
>><br>
>> OpenStack is considered healthy when OpenStack API services respond<br>
>> appropriately. Further OpenStack is<br>
>> healthy when network traffic can be sent between the tenant networks and<br>
>> can access the Internet. Finally OpenStack<br>
>> is healthy when all infrastructure cluster elements are in an<br>
>> operational state.<br>
>><br>
>> For information about blueprints check out:<br>
>> <a href="https://blueprints.launchpad.net/cloudpulse">https://blueprints.launchpad.net/cloudpulse</a><br>
>> <a href="https://blueprints.launchpad.net/python-cloudpulseclient">https://blueprints.launchpad.net/python-cloudpulseclient</a><br>
>><br>
>> For more details, check out our Wiki:<br>
>> <a href="https://wiki.openstack.org/wiki/Cloudpulse">https://wiki.openstack.org/wiki/Cloudpulse</a><br>
>><br>
>> Plase join the CloudPulse team in designing and implementing a<br>
>> world-class Carrier Grade system for checking<br>
>> the health of OpenStack clouds. We look forward to seeing you on IRC on<br>
>> #openstack-cloudpulse.<br>
>><br>
>> Regards,<br>
>> Vinod Pandarinathan<br>
>> [1] <a href="https://github.com/openstack-dev/cookiecutter">https://github.com/openstack-dev/cookiecutter</a><br>
>><br>
>><br>
>><br>
>> <br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <br>
>><a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font></div>
</div>
</span>
</body>
</html>