Description of problem: If /var/lib/ovirt-hosted-engine-ha/ha.conf provides a vendor provided configuration, then it should go to /usr/{lib,etc}/ovirt-hosted-engine-ha/ha.conf The user can customize/override it by copying it to /etc/ovirt-hosted-engine-ha. Placing it in /var/lib/ovirt-hosted-engine-ha/ is bad, because /var might be different at runtime, then how it is at install time, i.e. in image environemnts like Node. The error you get when the file is missing is: Sep 10 09:07:51 node.example.org vdsm[3391]: vdsm vds ERROR error setting HA maintenance mode Traceback (most recent call last): File "/usr/share/vdsm/API.py", line 1737, in setHaMaintenanceMode haClient.HAClient().set_maintenance_mode(mm, enabled) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 266, in set_maintenance_mode str(util.to_bool(value))) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/env/config.py", line 164, in set with open(self._dynamic_files[type], 'r+') as f: IOError: [Errno 2] No such file or directory: '/var/lib/ovirt-hosted-engine-ha/ha.conf'
Fabian, this file is not user editable, it should be coming from OVF store where it will be placed by the engine (to allow UI based management and to synchronize the file across all nodes). The crash is not good though.
I see, then, indeed it looks as if it's placed correctly, but - yes - then HA should not expect it to be there - or recreate it empty if needed.
If this file has vendor presets/defaults, then please move this file to some location in /usr. If this file has content which is edited by users, please move it to /etc. At best it should allow shadowing: First read from /usr, let it be overriden by /etc, This bug is still highly relevant for good upgrades paths of NGN.
This file is automatically generated every time hosted engine reads the data from the OVF store. It is not user editable and it does not contain any values you can modify or shadow from the host perspective (it should all be coming from the engine).
If it's getting auto-generated then the location seems to be fine - and I'm fine in closing this bug. One nit: What about putting it in /var/cache/ if it can be derived from another datasource?
> One nit: What about putting it in /var/cache/ if it can be derived from > another datasource? Not a bad idea actually.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
oVirt 4.0 beta has been released, moving to RC milestone.
For the record, comment 5 summarizes the status.
We can't use cache because we need that fallback configuration, and we want it to survive reboots. closing this.