Description of problem: Right now "opening" and "closing" event mails haven't got same Message-ID. Thus thread view inside mail clients is broken and both mails appear as separate mails event they are related. If would make sense and it would be super useful to have thread view on related event mails. Right now: -%- Message-ID: <1389460336.6.1382086603547.JavaMail.ovirt.redhat.com> Subject: Issue Solved Notification. (jb-rh33.rhev.lab.eng.brq.redhat.com), [Migration completed (VM: jb-w8-x86, Source: dell-r210ii-13, Destination: dell-r210ii-03, Duration: 41 sec).] -%- -%- Message-ID: <922689674.7.1382086605029.JavaMail.ovirt.redhat.com> Subject: Alert Notification. (jb-rh33.rhev.lab.eng.brq.redhat.com), [Migration started (VM: jb-w8-x86, Source: dell-r210ii-13, Destination: dell-r210ii-03, User: admin@internal).] -%- Version-Release number of selected component (if applicable): is19 How reproducible: 100% Steps to Reproduce: 1. start migration and have it successfully completed, have two mails sent 2. sort as thread view in your mail client 3. Actual results: each mail of one related action is separate mail as they have different message-id Expected results: let it work for old school users which like thread view (some these people this exist) :D Additional info:
Note that the correct e-mail header is most likely "References", not "Message-ID".
Two questions come to mind implementing this feature: 1. If the notifier is restarted should we still send the same message id? 2. If we have an up event (e.g migration from host 1 + success) and then another up event (e.g migration from host 2 + success) can we group these together too? The first issue dictated if we need to persist message ids. The second issue is if we only want to group only messages of the same objects we have to know to identify them as such and keep a unique id for each one.
(In reply to Mooli Tayer from comment #2) > Two questions come to mind implementing this feature: I can answer from mere user's point of view: > 1. If the notifier is restarted should we still send the same message id? Yes please. I as reader/receiver of those e-mails don't care about the sender. I just want to see messages logically grouped :-) > 2. If we have an up event (e.g migration from host 1 + success) and then > another > up event (e.g migration from host 2 + success) can we group these together > too? Personally, I would say "yes". From my point of view, all messages regarding the same object (VM/template/storage domain etc.) should be grouped together. > The first issue dictated if we need to persist message ids. Note that you can generate some unique message ID from other data. E.g. VM UUID+timestamp of last event recorded in RHEV-M database or something like that. See http://tools.ietf.org/html/rfc5322#section-3.6.4 for semantics of "References" header. > The second issue is if we only want to group only messages of the same > objects we have to know to identify them as such and keep a unique id for > each one. I naively thought that any object in RHEV has an UUID...
> > 2. If we have an up event (e.g migration from host 1 + success) and then > > another > > up event (e.g migration from host 2 + success) can we group these together > > too? > Personally, I would say "yes". From my point of view, all messages regarding > the same object (VM/template/storage domain etc.) should be grouped together. I would say 'NO'. This is different topic, references should correlate only UP|DOWN(if applicable) events, not 'objects'. It's like in thread-view in sane mail client, you want to "group" topics/subjects, not 'names' in subjects. Example: - foobar -- Re: foobar -- Re: Re: foobar - foobar is cool -- Re: foobar is cool
(In reply to Jiri Belka from comment #4) > > > 2. If we have an up event (e.g migration from host 1 + success) and then > > > another > > > up event (e.g migration from host 2 + success) can we group these together > > > too? > > Personally, I would say "yes". From my point of view, all messages regarding > > the same object (VM/template/storage domain etc.) should be grouped together. > > I would say 'NO'. This is different topic, references should correlate only > UP|DOWN(if applicable) events, not 'objects'. It's like in thread-view in > sane mail client, you want to "group" topics/subjects, not 'names' in > subjects. This depends on personal preference. From my point of view, messages regarding one object (e.g. VM) constitute one "topic". E.g. VM1 is up - VM1 migration from host1 to host2 started - VM1 migration from host1 to host2 finished - VM1 crashed on host hyper2 - VM1 restarted on host1 From my point of view, this has value because you can see whole history related to particular object directly in e-mail client. I understand that other people have other opinions. Can you make this configurable, please?
Arthur, This is something to be defined by PM, There are several approaches here (in the above comments) Personally I would go with grouping according to the Managed object, This will require to handle all the events that are not related to any managed object (e.g.DB) and to handle also all events that are related to more than one object (e.g. migration). So it means to go over all events and decide on each one which object it relates to. This will require a big effort for a small feature. Hence moving to rhevm-future.
Hmm, can we get some very basic implementation sooner than in "rhevm-future"? I mean - can you handle only the easy case for now and defer more advanced approaches? At least grouping per managed object would be useful. This can be limited to the case where managed objects exists, e.g. do grouping for a VM but ignore it for a database or so. Maybe it will show that the easy case is enough and "advanced" parts can be deffered even more :-) Thank you!
Please NO! Design it right and do it only once when you are really satisfied with its design. If one doesn't know how to do it right, then please do not do it! Shooting from a dark with some "working" implementation is soooo lame (and stupid and even more stupid if functionality changes in time).
This is some what related to: https://bugzilla.redhat.com/show_bug.cgi?id=1071197
Mooli, following our discussion please updated with suggested solution.
In light of other BZ, and recent notifier changes, (i.e integration with monitoring systems) I do not think our plans where comprehensive enough. further planning is needed.