Hi Simon, Thanks for your feedback. Please see inline.
From: Simon Pasquier <spasqu...@mirantis.com<mailto:spasqu...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, May 13, 2015 at 6:06 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments Hello, Like many others commented before, I don't quite understand how unique are the Cloudpulse use cases. For operators, I got the feeling that existing solutions fit well: - Traditional monitoring tools (Nagios, Zabbix, ....) are necessary anyway for infrastructure monitoring (CPU, RAM, disks, operating system, RabbitMQ, databases and more) and diagnostic purposes. Adding OpenStack service checks is fairly easy if you already have the toolchain. 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. - OpenStack projects like Rally or Tempest can generate synthetic loads and run end-to-end tests. Integrating them with a monitoring system isn't terribly difficult either. You put it well, right now the ask is simple and there is no solution that has integrated control/dataplane tests and made it flexible and configurable from both application and tenant perspective. We will levarage any of these existing tests as part of our comprehensive tests, which can be run by the operator on periodic basis with long intervals. At this point these tests cannot be run in short intervals since they are heavy weight, and several times the tests leave several orphan resources that needs manual cleanup. As far as Monitoring-as-a-service is concerned, do you have plans to integrate/leverage Ceilometer? Yes, that will be exposed as an extension, when some application/operator needs the data. Thanks Vinod. BR, Simon On Tue, May 12, 2015 at 7:20 PM, Vinod Pandarinathan (vpandari) <vpand...@cisco.com<mailto:vpand...@cisco.com>> 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 Dake and Vinod 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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
