[openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments

Vinod Pandarinathan (vpandari) vpandari at cisco.com
Wed May 13 17:23:15 UTC 2015



On 5/12/15, 2:43 PM, "Richard Raseley" <richard at raseley.com> wrote:

>
>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
>
>As others have expressed - I am a little skeptical about the need to
>'reinvent the wheel' with regards to monitoring.
>
>Are there a well-defined set of business or user requirements which
>would be enabled by CloudPulse which are not enabled by existing
>solutions? I am just trying to better wrap my need around the problem...

The solution is for health-checking, which includes periodically running
light/mid/heavy
Control and data plane tests and provide test data. The tool shall not
have any dependency on one particular monitoring tool
If monitoring tool is installed, then monitoring data shall be exposed to
the applications in a consumable fashion.
As I mentioned earlier, we are not replacing any monitoring solution
available out there we are leveraging those solutions
 and provide  a clean interface so that the application/tenants and
Operators know if the cloud is healthy.


Thanks
Vinod.

>
>Regards,
>
>Richard
>
>__________________________________________________________________________
>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




More information about the OpenStack-dev mailing list