Bug 1073524

Hi pter,

The first filter element here [include:*(snmp:)] is understood as:
send all events (*) to all snmp subscribers (snmp:)

In this case this is what happens;
In the flow described above, only the event VM_SET_TICKET is created in the audit_log so the notifier filter mechanism in this case works as expected.

So the bug is:
VM_CONSOLE_CONNECTED and VM_CONSOLE_DISCONNECTED are not created when opening and closing the spice console. I guess it is a bug although I'm not sure from the code...

Awaiting your response, 
I think we should edit the title and component of this bug(backend bug).

I lost the needinfo in the above comment due to a collision.

Oved,
I think this code should be familiar to you (VdsEventListener.java around line 230) should VM_CONSOLE_CONNECTED and VM_CONSOLE_DISCONNECTED audits be created in this case?
Could you say why they are not?

(In reply to Mooli Tayer from comment #1)
> The first filter element here [include:*(snmp:)] is understood as:
> send all events (*) to all snmp subscribers (snmp:)

Ok, I feel a little bit of confusion here from my side. Are the filter elements evaluated from right to left or from left to right? My intention was to include everything to the general profile, but blacklist VM_CONSOLE_CONNECTED from profile1. How should such filter look like? 

> In this case this is what happens;
> In the flow described above, only the event VM_SET_TICKET is created in the
> audit_log so the notifier filter mechanism in this case works as expected.
> 
> So the bug is:
> VM_CONSOLE_CONNECTED and VM_CONSOLE_DISCONNECTED are not created when
> opening and closing the spice console. I guess it is a bug although I'm not
> sure from the code...

No, thats not true. These events are generated and properly sent by snmp if FILTER="include:*(snmp:) ${FILTER}" is used. So my impression is it's really related to what is set as a filter in comment 0.

(In reply to Petr Beňas from comment #4)
> (In reply to Mooli Tayer from comment #1)
> > The first filter element here [include:*(snmp:)] is understood as:
> > send all events (*) to all snmp subscribers (snmp:)
> 
> Ok, I feel a little bit of confusion here from my side. Are the filter
> elements evaluated from right to left or from left to right? 

left to right.

> My intention
> was to include everything to the general profile, but blacklist
> VM_CONSOLE_CONNECTED from profile1. How should such filter look like? 

you came close, the only thing is that 'include:*(snmp:)' does not only apply to 
the default profile but to all. you can do:

FILTER="exclude:VM_CONSOLE_CONNECTED(snmp:profile1) include:*(snmp:) ${FILTER}"


> > In this case this is what happens;
> > In the flow described above, only the event VM_SET_TICKET is created in the
> > audit_log so the notifier filter mechanism in this case works as expected.
> > 
> > So the bug is:
> > VM_CONSOLE_CONNECTED and VM_CONSOLE_DISCONNECTED are not created when
> > opening and closing the spice console. I guess it is a bug although I'm not
> > sure from the code...
> 
> No, thats not true. These events are generated and properly sent by snmp if
> FILTER="include:*(snmp:) ${FILTER}" is used. So my impression is it's really
> related to what is set as a filter in comment 0.

That's what I saw when attempting to reproduce, but I'm glad to hear that works fine...

pter is it working as expected now?

Unfortunatelly not. With 
FILTER="exclude:VM_CONSOLE_CONNECTED(snmp:profile1) include:*(snmp:) ${FILTER}"
I'm not receiving any traps for profile1, while all notifications for the general profile seem to work as expected(including VM_CONSOLE_CONNECTED and VM_CONSOLE_DISCONNECTED).

I'm getting impression there's really something wrong with how the FILTER is parsed. 

Aren't the filter elements actually evaluated from right to left? If they were read from right to left, then the elements at the end of the filter line would override the ones laying at the beginning. I got impression the opposite is true (not mentioning this bug), that the more specific elements should go to the left and the more generic to the right, as shown in the example. But this is just my understaning of the thing which can be far from reality.

OK.
I was wrong (sorry) this is what you need:

FILTER="exclude:VM_CONSOLE_CONNECTED(snmp:profile1) include:*(snmp:) include:*(snmp:profile1) ${FILTER}"


Clarifying my confusion: while writing no protocol will match all (e.g include:*  will get a message delivered to all subscribers) writing snmp: still matches only the default profile so in the previous filter we have nothing that says to send something to profile1.

I will attach notifier_correct.log so that you can see that VM_CONSOLE_CONNECTED was sent only to default snmp profile while  VM_SET_TICKET and VM_CONSOLE_DISCONNECTED are send to both default and profile1 profiles (of course you should verify yourself)

About your question on the order of evaluation I am sure it is from left to right.
Notice a user can do FILTER="new_rule ${FILTER}" to make new_rule take first precedence or FILTER="${FILTER} new_rule" to make his rule take last.

Those this make sense? can we close this as not a bug?

Created attachment 876030 [details]
log where events are sent to the correct filters.

(In reply to Mooli Tayer from comment #8)
Yes, confirmed it works in av3. But it looks like there must have been some change. All of lollowing works: 

a) FILTER="exclude:VM_CONSOLE_CONNECTED(snmp:profile1) include:*(snmp:) include:*(snmp:profile1) ${FILTER}" 
b) FILTER="include:*(snmp:) exclude:VM_CONSOLE_CONNECTED(snmp:profile1) include:*(snmp:profile1) ${FILTER}"
c) FILTER="exclude:VM_CONSOLE_CONNECTED(snmp:profile1) include:*(snmp:profile1) ${FILTER} include:*(snmp:)"

Baseed on these av3 test resutlt, it seems to be correct what you claim in comment 8, that "include:*(snmp:)" does not affect profile1 at all. I'm just wondering, the b) is exactly the same filter as I reported in comment 0 as not working in av2. So I'm ok with closing the bug since it works now, but is it possible it got fixed with the patch for multiple managers or another patch between av2 and av3?

Afaik there were no changes in the filtering algorithm.

Is it possible that when the bug was opened only VM_SET_TICKET was present in the audit_log table(that would explain what you saw and also what I described in comment 1)? so maybe sometimes VM_CONSOLE_CONNECTED and VM_CONSOLE_DISCONNECTED are not created for some reason?

In the future in such cases if we have the relevant audit_log records as an attachment (rather then a description of the flow that created them) they should help understand what happened and also make reproducing the bug easier.