Description of problem: I've tried API for events and found these issues: 1) /events?severity= result: [] but in other filter options if value is not set it ignores this filter and return all events 2) any wrong value of param should return error, for example /events?pageno=-1&pagesize=1. In case of pagination wrong values are: negative number, float number, zero, invalid datetimes 3) if index is out of range for pagination it should return error: /events?pageno=19&pagesize=1 {"totalcount":18,"startindex":18,"endindex":18,"events":[ {"event_id":"00000000-0000-0000-0000-000000000000","cluster_id":"00000000-0000-0000-0000-000000000000","cluster_name":"","notificationentity":0,"entityid":"00000000-0000-0000-0000-000000000000","node_id":"00000000-0000-0000-0000-000000000000","nodename":"","timestamp":"0001-01-01T00:00:00Z","name":"","tags":null,"message":"","description":"","severity":0,"correlationid":"00000000-0000-0000-0000-000000000000","acked":false,"ackedtime":"0001-01-01T00:00:00Z","ackedby":"","ackcomment":"","notify":false,"notified":false}]} 4) there are 2 states for same result - empty list: a) returns error - 500 internal server error /events?pageno=3&pagesize=18" b) empty list /events?pageno=2&pagesize=18" {"totalcount":18,"startindex":18,"endindex":17,"events":[]} 5) this should be empty list but it returns all events: /events?fromdatetime=2006-01-02T15:04:05Z07:00&todatetime=2006-01-02T15:04:05Z07:01" 6) /events?fromdatetime=20016-03-09T00:00:00.000Z&todatetime=2016-04-01T00:00:00.000Z" | sed 's/{"event_id"/\n{"event_id"/g' | grep 'timestamp":"2016-03-08' {"event_id":"f9b7e641-1d42-4a40-838f-783a31fc0b9d","cluster_id":"d4f92050-4ebc-4398-821b-c27ee368b85c","cluster_name":"testcl","notificationentity":0,"entityid":"7e528229-0c2f-4ba7-a89a-cbbd742e32c5","node_id":"7e528229-0c2f-4ba7-a89a-cbbd742e32c5","nodename":"mkudlej-usm2-node5.os1.phx2.redhat.com","timestamp":"2016-03-08T19:53:44.538+01:00","name":"Node contact gained","tags":{},"message":"Host: mkudlej-usm2-node5.os1.phx2.redhat.com gained contact","description":"","severity":5,"correlationid":"00000000-0000-0000-0000-000000000000","acked":false,"ackedtime":"0001-01-01T00:00:00Z","ackedby":"","ackcomment":"","notify":true,"notified":false}, {"event_id":"a9416359-1a02-4196-9f4b-dcd0674fdfe6","cluster_id":"d4f92050-4ebc-4398-821b-c27ee368b85c","cluster_name":"testcl","notificationentity":0,"entityid":"7e528229-0c2f-4ba7-a89a-cbbd742e32c5","node_id":"7e528229-0c2f-4ba7-a89a-cbbd742e32c5","nodename":"mkudlej-usm2-node5.os1.phx2.redhat.com","timestamp":"2016-03-08T19:52:42.646+01:00","name":"Node contact lost","tags":{},"message":"Host: mkudlej-usm2-node5.os1.phx2.redhat.com lost contact","description":"","severity":0,"correlationid":"00000000-0000-0000-0000-000000000000","acked":false,"ackedtime":"0001-01-01T00:00:00Z","ackedby":"","ackcomment":"","notify":true,"notified":false}, {"event_id":"dbc3a9ba-4ea3-48a6-99cf-325f804172c6","cluster_id":"00000000-0000-0000-0000-000000000000","cluster_name":"","notificationentity":0,"entityid":"e3db64a7-853e-46fd-88a5-812617e292ae","node_id":"e3db64a7-853e-46fd-88a5-812617e292ae","nodename":"mkudlej-usm2-node1.os1.phx2.redhat.com","timestamp":"2016-03-08T12:19:28.617+01:00","name":"Node contact gained","tags":{},"message":"Host: mkudlej-usm2-node1.os1.phx2.redhat.com gained contact","description":"","severity":5,"correlationid":"00000000-0000-0000-0000-000000000000","acked":false,"ackedtime":"0001-01-01T00:00:00Z","ackedby":"","ackcomment":"","notify":true,"notified":false}, {"event_id":"0100d431-43f0-4d51-9f1d-5fed51cce863","cluster_id":"00000000-0000-0000-0000-000000000000","cluster_name":"","notificationentity":0,"entityid":"7e528229-0c2f-4ba7-a89a-cbbd742e32c5","node_id":"7e528229-0c2f-4ba7-a89a-cbbd742e32c5","nodename":"mkudlej-usm2-node5.os1.phx2.redhat.com","timestamp":"2016-03-08T12:19:28.617+01:00","name":"Node contact gained","tags":{},"message":"Host: mkudlej-usm2-node5.os1.phx2.redhat.com gained contact","description":"","severity":5,"correlationid":"00000000-0000-0000-0000-000000000000","acked":false,"ackedtime":"0001-01-01T00:00:00Z","ackedby":"","ackcomment":"","notify":true,"notified":false}]} Version-Release number of selected component (if applicable): rhscon-core-0.0.8-11.el7.x86_64 rhscon-ceph-0.0.6-11.el7.x86_64 rhscon-ui-0.0.21-1.el7.noarch How reproducible: 100%
rhscon-ceph-0.0.6-14.el7.x86_64 rhscon-core-0.0.8-14.el7.x86_64 rhscon-ui-0.0.23-1.el7.noarch 7) It is not possible to search events with nodename == ""(query /events?nodename=) but there are events with nodename == ""
(In reply to Martin Kudlej from comment #1) > rhscon-ceph-0.0.6-14.el7.x86_64 > rhscon-core-0.0.8-14.el7.x86_64 > rhscon-ui-0.0.23-1.el7.noarch > > 7) It is not possible to search events with nodename == ""(query > /events?nodename=) but there are events with nodename == "" Nodename is not relevant to few events like events which are related to cluster state. So the node name is left blank for them. So nodename = "" means nodename is not relevant to them. So I feel filtering all events with node "" is logically not correct as "" is not actually a nodename. Also If we decide to provide this functionality by listing events with nodename "" when "/events?nodename=" is passed. It becomes inconsistent with query parameters as we list everything when value is not passed for other parameters. I feel its better to leave this functionality as is.
Tested with ceph-ansible-1.0.5-31.el7scon.noarch ceph-installer-1.0.14-1.el7scon.noarch rhscon-ceph-0.0.34-1.el7scon.x86_64 rhscon-core-0.0.35-1.el7scon.x86_64 rhscon-core-selinux-0.0.35-1.el7scon.noarch rhscon-ui-0.0.49-1.el7scon.noarch and 1) works 2) works 3) works 4) works 5) works 6) works --> Verified