Comment 4 for bug 1830615

Looking later glusterfs-server package from Cosmic and late, the tendency is to have glustereventsd disabled, in order to stay consistent with the more modern package, this can be one avenue to fix the situation

Of course, I haven't look nor discuss about upgrading to a more recent (non-eol version).
But this eol/non-eol discussion can still happen separately later on even after we have fix that particular install breakage issue.

I built a test package with the disabling glustereventsd part, and installed it in a test container:

...
glusterd.service is a disabled or a static unit, not starting it.
glustereventsd.service is a disabled or a static unit, not starting it.
...

$ systemctl is-enabled glustereventsd.service
disabled

If I start it manually, everything works now, and the installation goes smooth.

$ systemctl start glustereventsd.service

$ systemctl status glustereventsd.service
● glustereventsd.service - Gluster Events Notifier
Loaded: loaded (/lib/systemd/system/glustereventsd.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2019-05-27 17:47:14 UTC; 1s ago
Main PID: 6175 (glustereventsd)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/glustereventsd.service
├─6175 /usr/bin/python2 /usr/sbin/glustereventsd --pid-file /var/run/glustereventsd.pid
└─6176 /usr/bin/python2 /usr/sbin/glustereventsd --pid-file /var/run/glustereventsd.pid

The only downside, is that one shouldn't expect glusterfseventsd to be up and running after the installation, but it's better that current situation where nothing is installable at all.