<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<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" <Kevin.Fox@pnnl.gov> 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 [jaypipes@gmail.com]<br>
>Sent: Tuesday, May 12, 2015 10:48 AM<br>
>To: openstack-dev@lists.openstack.org<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>
>>OpenStack-dev-request@lists.openstack.org?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: OpenStack-dev-request@lists.openstack.org?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: OpenStack-dev-request@lists.openstack.org?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: OpenStack-dev-request@lists.openstack.org?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>
</body>
</html>