[openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments
Richard Raseley
richard at raseley.com
Tue May 12 21:43:21 UTC 2015
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...
Regards,
Richard
More information about the OpenStack-dev
mailing list