Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Wasn't aware of this (or bug 1335503) so far. My own 2c:

1. We should clarify somewhere that you should have a configured and functional mail server on each HA host, if you expect to get email notifications from them, and if you accept the defaults of the deploy process (which are to send them to localhost). I think we already mention this somewhere.

2. I'd expect all sysadmins to (also) forward these emails to some other, external, address, eventually reaching a human (or some ticketing/alerting system or whatever). Perhaps we should also mention this.

3. For the IMO quite unlikely case of an admin taking care to configure a local mail server but not aliasing/forwarding to an external address, IMO we should not require mailx (or nail, or mutt, or whatever), but let the admin decide. In most cases, for emergencies, 'less(1)' is probably good enough, no need to carry more dependencies.

(In reply to Yedidyah Bar David from comment #2)
> Wasn't aware of this (or bug 1335503) so far. My own 2c:
> 
> 1. We should clarify somewhere that you should have a configured and
> functional mail server on each HA host, if you expect to get email
> notifications from them, and if you accept the defaults of the deploy
> process (which are to send them to localhost). I think we already mention
> this somewhere.

This should be covered already by ovirt-hosted-engine-setup related documentation.
@sgoodman can you please confirm?

> 2. I'd expect all sysadmins to (also) forward these emails to some other,
> external, address, eventually reaching a human (or some ticketing/alerting
> system or whatever). Perhaps we should also mention this.


I think this is up to the sysadmin, I expect them to know what they are doing


> 3. For the IMO quite unlikely case of an admin taking care to configure a
> local mail server but not aliasing/forwarding to an external address, IMO we
> should not require mailx (or nail, or mutt, or whatever), but let the admin
> decide. In most cases, for emergencies, 'less(1)' is probably good enough,
> no need to carry more dependencies.

I think the original bug was to be able to easily read mail sent to local root user.

(In reply to Sandro Bonazzola from comment #3)
> (In reply to Yedidyah Bar David from comment #2)
> > 3. For the IMO quite unlikely case of an admin taking care to configure a
> > local mail server but not aliasing/forwarding to an external address, IMO we
> > should not require mailx (or nail, or mutt, or whatever), but let the admin
> > decide. In most cases, for emergencies, 'less(1)' is probably good enough,
> > no need to carry more dependencies.
> 
> I think the original bug was to be able to easily read mail sent to local
> root user.

Yes, that's exactly what I meant - our messages are ASCII, and you can read
them with 'less /var/mail/root' if that's where mail to root goes. Indeed
you can't manipulate the mailbox with 'less', but that's IMO not a good
enough reason to require an MUA on each host.

So, if that's the only reason, IMO we should just remove the requirement.

(In reply to Sandro Bonazzola from comment #3)
> (In reply to Yedidyah Bar David from comment #2)
> > 1. We should clarify somewhere that you should have a configured and
> > functional mail server on each HA host, if you expect to get email
> > notifications from them, and if you accept the defaults of the deploy
> > process (which are to send them to localhost). I think we already mention
> > this somewhere.
> 
> This should be covered already by ovirt-hosted-engine-setup related
> documentation.
> @sgoodman can you please confirm?

This is all that we say about email:

----
(From the SHE installation guide)
21. Provide the name and TCP port number of the SMTP server, the email address used to send email notifications, and a comma-separated list of email addresses to receive these notifications. Alternatively, press Enter to accept the defaults [1] 
----

and

Configuring Email Notifications [2] in the Admin Guide.


So should we add to the Planning and Prerequisites Guide under "Self-Hosted Engine Recommendations" [3] the following:

> You should have a configured and functional mail server on each HA host, if you expect to get email notifications from them, and if you accept the defaults of the deploy process (which are to send them to localhost).


[1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html-single/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_command_line#Deploying_the_Self-Hosted_Engine_Using_the_CLI_install_RHVM
[2] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html-single/administration_guide#configuring_email_notifications
[3] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html-single/planning_and_prerequisites_guide/index#self-hosted-engine-recommendations

(In reply to Steve Goodman from comment #5)
> So should we add to the Planning and Prerequisites Guide under "Self-Hosted
> Engine Recommendations" [3] the following:
> 
> > You should have a configured and functional mail server on each HA host, if you expect to get email notifications from them, and if you accept the defaults of the deploy process (which are to send them to localhost).

Yes, this makes sense. Perhaps something like:

HA setup defaults to configuring HA to send email notifications to a mail server on the local machine.

A mail server is not configured on the local machine by default, so these notifications will be lost.

If you want to get such notifications, you should either change the default when prompted, and provide details of your mail server, or configure a local mail server on each HA host.

Didi already answered to needinfo from comment #5 with comment #6

# yum deplist http://mirror.stream.centos.org/SIGs/9-stream/virt/x86_64/ovirt-45/Packages/o/ovirt-host-4.5.0-3.el9.x86_64.rpm | grep -E "mailx|s-nail"
ovirt-host-4.5.0-3.el9.x86_64.rpm                41 kB/s |  12 kB     00:00    
  dependency: s-nail