Open Stack

Great Idea.  I have seen this request coming from multiple folks.

Especially to detect key events through Zaqar and pass it on to  the application, which can then take app specific action.

Thanks
Vinod.

From: <Fox>, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, May 12, 2015 at 12:51 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments

Hooking it into Zaqar would be awesome too. Once you can trigger Mistral workflows based on Zaqar messages, just imagine the possibilities...

Kevin

________________________________
From: Steven Dake (stdake)
Sent: Tuesday, May 12, 2015 12:02:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments

Kevin,

This is a great idea that would make a solid extension to the software.
If I read the wiki page correctly, the real goal is for operators and
tenants to be able to be notified via querying the ReST API so they could
write their own email/pager-duty app.

Regards
-steve

On 5/12/15, 11:16 AM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:

>Nagios/watever As A Service would actually be very useful I think.
>
>Setting up a monitoring server is a fair amount of work. If "Cloud Apps"
>downloaded from an OpenStack Catalog had a Monitoring Heat resource built
>in, that would register the launched app with a multitenant aware Cloud
>Monitoring Service, the user would only have to launch an app, and then
>go into the Dashboard and associate some kind of alerting policy with the
>registered checks. Say, email this address when things break. That would
>be awesome. :)
>
>Thanks,
>Kevin
>________________________________________
>From: Jay Pipes [jaypipes at gmail.com<mailto:jaypipes at gmail.com>]
>Sent: Tuesday, May 12, 2015 10:48 AM
>To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
>Subject: Re: [openstack-dev] [new][cloudpulse] Announcing a project to
>HealthCheck OpenStack deployments
>
>For operators:
>
>* Nagios
>* Icinga
>* Zabbix
>
>installed on baremetal machines deployed with the OpenStack and other
>infrastructure services.
>
>For tenants:
>
>* Nagios
>* Icinga
>* Zabbix
>
>installed on their VMs.
>
>Why are we re-inventing excellent open-source implementations of
>monitoring systems that have been around for over a decade?
>
>Best,
>-jay
>
>p.s. Sorry for top-posting.
>
>On 05/12/2015 01:20 PM, Vinod Pandarinathan (vpandari) wrote:
>> Hello,
>>
>>    I'm pleased to announce the development of a new project called
>> CloudPulse.  CloudPulse provides Openstack
>> health-checking services to both operators, tenants, and applications.
>> This project will begin as
>> a StackForge project based upon an empty cookiecutter[1] repo.  The
>> repos to work in are:
>> Server: https://github.com/stackforge/cloudpulse
>> Client: https://github.com/stackforge/python-cloudpulseclient
>>
>> Please join us via iRC on #openstack-cloudpulse on freenode.
>>
>> I am holding a doodle poll to select times for our first meeting the
>> week after summit.  This doodle poll will close May 24th and meeting
>> times will be announced on the mailing list at that time.  At our first
>> IRC meeting,
>> we will draft additional core team members, so if your interested in
>> joining a fresh new development effort, please attend our first meeting.
>> Please take a moment if your interested in CloudPulse to fill out the
>> doodle poll here:
>>
>> https://doodle.com/kcpvzy8kfrxe6rvb
>>
>> The initial core team is composed of
>> Ajay Kalambur,
>> Behzad Dastur, Ian Wells, Pradeep chandrasekhar, Steven DakeandVinod
>> Pandarinathan.
>> I expect more members to join during our initial meeting.
>>
>>   A little bit about CloudPulse:
>>   Cloud operators need notification of OpenStack failures before a
>> customer reports the failure. Cloud operators can then take timely
>> corrective actions with minimal disruption to applications.  Many cloud
>> applications, including
>> those I am interested in (NFV) have very stringent service level
>> agreements.  Loss of service can trigger contractual
>> costs associated with the service.  Application high availability
>> requires an operational OpenStack Cloud, and the reality
>> is that occascionally OpenStack clouds fail in some mysterious ways.
>> This project intends to identify when those failures
>> occur so corrective actions may be taken by operators, tenants, and the
>> applications themselves.
>>
>> OpenStack is considered healthy when OpenStack API services respond
>> appropriately.  Further OpenStack is
>> healthy when network traffic can be sent between the tenant networks and
>> can access the Internet.  Finally OpenStack
>> is healthy when all infrastructure cluster elements are in an
>> operational state.
>>
>> For information about blueprints check out:
>> https://blueprints.launchpad.net/cloudpulse
>> https://blueprints.launchpad.net/python-cloudpulseclient
>>
>> For more details, check out our Wiki:
>> https://wiki.openstack.org/wiki/Cloudpulse
>>
>> Plase join the CloudPulse team in designing and implementing a
>> world-class Carrier Grade system for checking
>> the health of OpenStack clouds.  We look forward to seeing you on IRC on
>> #openstack-cloudpulse.
>>
>> Regards,
>> Vinod Pandarinathan
>> [1] https://github.com/openstack-dev/cookiecutter
>>
>>
>>
>>
>>_________________________________________________________________________
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150513/74ae0df2/attachment-0001.html>