On 05/12/2015 02:24 PM, Vinod Pandarinathan (vpandari) wrote:
Very True. However the way I see these are extensions/plugins to
cloudpulse framework, so when these are available, the data from these
tools are exposed.
Openstack health service provides an overall framework with out
assumptions on what is installed on the underlying cloud.
The service is expected to run on existing cloud deployments that may or
may not have any of this software (from tenant as well).
You mean, like Monasca?
https://wiki.openstack.org/wiki/Monasca
Sounds to me like you will at the very least need an agent of some sort
on the VMs to communicate to an external system. And, that is the
monasca-agent:
https://github.com/stackforge/monasca-agent
ala Nagios NRPE agent:
http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf
ala Zabbix agent:
https://www.zabbix.com/documentation/2.0/manual/concepts/agent
ala Icinga agent:
http://docs.icinga.org/latest/en/nrpe.html
So, cloudpulse would be yet another agent for sending healthcheck
messages to an external system, in order for the framework "not to make
any assumptions on what is insyalled in the underlying cloud" -- other
than the assumption you'd need yet another agent installed.
Core health checks for operators and tenants test basic openstack services
which are present in any openstack cloud.
Operators != tenants. Trying to make the two equal each other and you
end up with Ceilometer and Triple-O -- with all the accompanying
complexity therein.
Best,
-jay
Thanks for the feedback.
Thanks
Vinod.
On 5/12/15, 10:48 AM, "Jay Pipes" <jaypi...@gmail.com> 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?
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-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
__________________________________________________________________________
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
__________________________________________________________________________
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
