[Users] API read-only access / roles

[Sander Grendelman]

On Mon, Nov 18, 2013 at 5:18 PM, René Koch (ovido) <r.koch at ovido.at> wrote:
> Very nice - do you use my check_rhev3 Nagios plugin
> (https://github.com/ovido/check_rhev3) or are you working on
> your own script?

At the moment: both. The problem with using Nagios scripts in Zabbix is that
the trigger/alarm decision is made in different places. In Nagios this is done
in the check scripts / on the "client" side while Zabbix mainly
collects data and
fires triggers if certain conditions in that data are met.

New(er) Zabbix versions also have a feature called "low level discovery" that
automatically creates items.

It also seems that there is better RESTful/ovirt API support in python
so I'm giving
that a try too. Although perl is usually my poison of choice too ;)

>> For this I've created a "AdminLoginOnly" role that only has
>> System->Configure System->Login Permissions access.
>>
>> Is this the way to go for this king of configuration? Or is there
>> a way to further minimize the permissions of this user?
>
> I create a custom role with these permissions for Nagios monitoring,
> too.
> I was thinking that in oVirt 3.3 there should be a predefined
> viewers-role, but can't find it in my setup :(

OK, that would have been nice, do you have any history on this one?

>> Another issue is that a "Login" event is generated every time
>> the user connects through the API. This makes the "Events"
>> pane less useful / readable. Is there a way to disable this for
>> some users/roles?
>
>
> It depends if you have your own script or check_rhev3:
> - check_rhev3 1.2: use option -o
> - check_rhev3 1.3: you should not see any login information in this
> version anymore
> - custom script: see this page on information how to use the JSESSIONID
> cookie: http://www.ovirt.org/Features/RESTSessionManagement

Thanks for the info I'll look into this.

It does make the logic in the script a bit harder because you have to store
the sessionid somewhere and check if the session is still valid.