On Wed, 2013-11-13 at 21:05 +0530, Sahina Bose wrote:
On 11/13/2013 08:53 PM, Itamar Heim wrote:
> On 11/13/2013 10:20 AM, Sahina Bose wrote:
>>
>> On 11/13/2013 08:20 PM, Itamar Heim wrote:
>>> On 11/13/2013 09:27 AM, René Koch (ovido) wrote:
>>>> Hi,
>>>>
>>>> There are 2 features I can maybe add to existing projects of mine
>>>> (check_rhev3 and Monitoring UI-Plugin), but it would be good to know
>>>> what users require to decide if this can be done via an external
>>>> (ui)plugin or if this needs to be integrated into oVirt itself.
>>>>
>>>> * gluster: Monitoring (UI plugin)
>>>> What's expected here - monitoring glusterfs volumes (including
>>>> performance data) and displaying the results in your favored
>>>> monitoring
>>>> solution and oVirt?
>>>
>>> vijay/dpati/sahina - thoughts on this one?
>> At a high level,
>>
>> Monitoring of volume
>> Storage metrics - capacity, network, CPU, disk utilization
>> Detecting split-brain/self-heal activity
>
> would help specyfing which REST API calls are involved.
Hmm.. would monitoring work on top of engine via REST API calls? I was
thinking more in line of monitoring the nodes directly - maybe a push
mechanism from nodes.
The advantage of monitoring via REST-API is that you don't need an
agent/script installed on the host/node. Especially for oVirt node I
think this is a huge advantage (haven't looked into 3rd party plugin
support yet).
The downside of it is that if REST-API isn't available (e.g. due to
engine maintenance jobs) you can't monitor your environment...
Especially for Nagios both options are valid - gathering data from
REST-API or directly from the host. Other monitoring solutions may
require an agent (or maybe snmp) on the host if data aren't available
via REST-API...
>
>>
>> Vijay/Dusmant - please add.
>>
>>>
>>>>
>>>> * other: Zabbix monitoring
>>>> Monitoring the oVirt environment should work with my check_rhev3
>>>> plugin
>>>> by adding it as an external check to Zabbix. I'll test this and if
>>>> it's
>>>> working I'll provide a short guide on how to do it.
>>>> Displaying data/triggers in oVirt isn't possible yet with my
>>>> Monitoring
>>>> UI-plugin, but on the feature list (help is welcome)...
>>>>
>>>>
>>>> Before I add myself to the list - can you give me more information on
>>>> the role/tasks of a testing owner? Are there more steps required then
>>>> testing a feature, getting in contact with the devel owner to fix
>>>> issues
>>>> and update the oVirt BZ (and join the IRC weekly meetings)?
>>>
>>> communicate with the other two owner on scope of what to test, then
>>> when feature is ready - test it, open bugs, and communicate if too
>>> broken to be considered in the version, etc.
>>>
>>>>
>>>>
>>>> Regards,
>>>> René
>>>>
>>>>
>>>>
>>>> On Tue, 2013-10-29 at 19:46 +0200, Itamar Heim wrote:
>>>>> To try and improve 3.4 planning over the wiki approach in 3.3,
I've
>>>>> placed the items i collected on users list last time into a google
>>>>> doc[1]
>>>>>
>>>>> now, the main thing each item needs is a requirements owner, devel
>>>>> owner
>>>>> and a testing owner (well, devel owner is really needed to make it
>>>>> happen, but all are important).
>>>>>
>>>>> then we need an oVirt BZ for each, and for some a feature page.
>>>>>
>>>>> I also added columns indicating if the item will require an API
>>>>> design
>>>>> review and a GUI design review.
>>>>>
>>>>> this list is just the start of course for items from it to get
>>>>> ownership. i expect more items will be added as well, as long as
they
>>>>> have owners, etc.
>>>>>
>>>>> the doc is public read-only, please request read-write access to be
>>>>> able
>>>>> to edit it.
>>>>>
>>>>> feel free to ask questions, etc.
>>>>>
>>>>> Thanks,
>>>>> Itamar
>>>>>
>>>>>
>>>>> [1]
http://bit.ly/17qBn6F
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users(a)ovirt.org
>>>>>
http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>
>>
>