Open Stack

There are several differences:

1. Cloudpulse does not need any agent or special software installed on the
underlying cloud, the service can be installed on a tenant VM having
access to API network.

2. Cloudpulse can be configured for running specific test groups
periodically exercising core open stack services.

3. Monasca is interesting, cloudpulse differs in the sense that it
provides pluggable extensions/api-tests (manipulate resources
Vms/networks/etc), flexible enough for the operator or the
application/tenant configure the time-interval and test-group that has to
run.

4. In addition Cloudpulse uses Openstack infra components without
complexity of kafka/zookeeper/spark etc.

Thanks
Vinod.

On 5/12/15, 12:59 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

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