Deprecated config check during Omnibus preinstall is involved for upgrades and not automation friendly
During Omnibus preinstall a config check is run to check for any deprecated config being present in an existing install. It's fairly rare for config to be fully deprecated but when this does happen the Omnibus package fails to install entirely.
This makes a lot of sense for normal installs where reconfigure is run as it calls out to users about deprecated config clearly but it does also introduce some complexities:
- Since Omnibus fails to install for users to be unlocked the guidance appears to be that they need follow an involved path to upgrade - Change Config, Reconfigure, Install, Reconfigure. Additionally this doesn't look to be called out in docs.
- The above isn't automation friendly and more of a design for manual installs where it's notably more efficient to be able to install Omnibus first concurrently then update config and reconfigure. Trying to guard against this in automation is difficult (such as handling upgrades across various minor versions) without following the above involved design as it stands which will add a notable amount of runtime and complexity.
In addition to the above there's a point of view here that deprecated config shouldn't be a full blocker per se across the board. Most config will just become stale and no longer picked up in code and in turn have no effect.
Issue is to discuss if we can make this more graceful and automation friendly. Happy to explore any option.
Edited by Grant Young