Open Stack

On 05/12/15 20:48, Jay Pipes wrote:
> 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?
>
Because that is what we love to do here in the OpenStack Community??
(Sorry I could not resist... :) )

But seriously though - do we have a set of tools that can do this - in a 
simple - consolidated way?
> 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
-- 
Best Regards,
Maish Saidel-Keesing