Open Stack

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?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>