Description of problem: modify osinfo part to read both files in /etc/ovirt-engine/osinfo.conf.d and /usr/share/ovirt-engine/conf/osinfo-defaults.properties current symlink kung-fu is odd. it's a hack because current engine it cannot read osinfo-defaults.properties from /usr. README file is enough in /etc/ovirt-engine/osinfo.conf.d/. this would also prevent replacements of "wrong" modifications of 00-defaults.properties. Version-Release number of selected component (if applicable): is23 How reproducible: 100% Steps to Reproduce: 1. engine is not reading directly /usr/share/ovirt-engine/conf/osinfo-defaults.properties at all 2. 3. Actual results: engine reads osinfo defaults only because there's hacking symlink Expected results: read both user modified files and defaults from files shipped with product Additional info: no software should modify just like that anything in /etc. and this was the case. it's a ugly approach.
iirc redhat-support-plugin-rhev is more clever, it reads configs both from /etc and /usr :)
can you please clarify what you mean? stop by if you want:)
It should read both config files in /usr (it is not doing now) and /etc. It reads data from /usr by symlink hack now. If we would delete the symlink it should read data from /usr by itself.
Hi, defaults of osinfo should read only /usr/share. if user wishes to provide its own file, he should install new osinfo configuration file redirect to where ever his file is. we should provide upgrade to remove /etc/ovirt-engine/sysprep files if they are default and to whatever left to generate osinfo configuration file to make use of user's custom files. Thanks,
Also, please add ${xxx} syntax to pull xxx out of EngineLocalConfig::getProperty() so that we can add ${ENGINE_ETC} or ${ENGINE_DATA} or even user defined variable at /etc/ovirt-engine/engine.conf,d/xxx.conf
sorry, I hijacked a bug... as was referred to at other subject, please ignore comment#3, comment#5.
For the subject at hand. I reject the idea to read both location, I find that one symlink of default makes it easier to understand what actually is being used without knowing product internals. If for some reason someone is to force that to be "fixed" the defaults file should be read before /etc processing.
(In reply to Alon Bar-Lev from comment #7) I concur