Open Stack

On 05/12/2015 05:05 PM, Vinod Pandarinathan (vpandari) wrote:
> 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.

Cloudpulse doesn't yet exist, so I think saying it is different from 
these things before it has anything to be different about is a bit 
premature.

Again, I'd highly advise those folks involved in this effort to take a 
look at the existing solutions in this space and perhaps find ways to 
collaborate and improve on what already exists.

Best,
-jay

> 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
>
>
> __________________________________________________________________________
> 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
>