Long time freeipa users have faced a certain 'fragility' freeipa has
inherited, mostly as a result of freeipa being the 'band director' over
a number of distinct subsystems maintained by various groups across the
world.
This or that 'little upgrade' in a seemingly small sub-part of freeipa
'suddenly breaks' major things like not being able to install a replica
& etc, there's a quite a list and it's been going on for a few years at
least to my knowledge. Usually one expects newer features to have bugs
but none that disrupt core prior functionality.
I wonder whether it would be a solution to this if free-ipa took a look
at how a 'similar feeling' multi-host, multi-subsystem architecture has
appeared to have solved this puzzle: ceph's 'containers' and
'orchestrator' / cephadm / 'ceph orch' concept.
For some time, as freeipa, ceph relied on packages and 'dependency hell
management' to operate as native packages across hosts connected on an
internal network. Then in a very effective shift: they treated 'the
contents of a container' much as 'one thing owned entirely by and
released by ceph' and tested that -- each container housing known-good
versions of dependent and third party modules as well as their own code
-- 'as one thing', to the point of providing their own tool to
'download and manage upgrade installs in the proper sequence' across
hosts providing this-or-that functionality.
You might imagine a freeipa orchestrator upgrading masters and replicas
in the correct order, freeipa devs knowing for certain-sure that no 'dnf
upgrade' on the host will disrupt the setup that passed qa in the
container... Will not 'corrupt a database' owing to a 'sync' with
content one version understood but another did not, etc.
Over these many months, while freeipa has struggled to provide
consistent service and value, ceph has been working nearly flawlessly
across many upgrade cycles and I think it's because ceph controls the
versions of the subsystems in the containers-- and that improves QA and
dramatically limits surprise breakages' that lead to the feeling of
'always catching up' under conditions of time pressure owing to down
services, this or that distro's 100 package mantainers deciding when/if
to include this/that patch and when to publish which new version, which
are 'security updates', which are 'bug fix updates', etc. If freeipa
server came in a container that was tested and QA'd as a container,
deployed as a container, perhaps the 'fragility factor' would improve by
10x.
My $0.02