In our environment there is heavy deployment rate for VMs, which are managed through
FreeIPA. Those VMs are scattered through different VDC and generelly current scheme is to
place two replicas in every VDC for the hosts in there. This ended up in overcomplicating
the replicas topology.
1) Also some hosts are using ipa api a quiet a lot and if host that is prescripted in the
/etc/ipa/default.conf is returning for example GSSAPI error or Replica Read timeout the
request is not getting served to another hosts in SRVs.
2) Also if replica is fine maybe I still don't want it to manage all of the request
from hosts to ipa api, just because during enrollment it ended up in xmlrpc_uri option.
3) The same goes for the enrollment - when something is wrong with replica through which
enrollment process is made I just want smooth failover process, failed replica is excluded
from requests handling, but the process finishes fine.
4) sssd experience when some of the replicas are not reachable, and there are a lot of srv
records has not been great. Though Ipa Locations help a bit.
For now I can get a single entry point for WebUI, LDAP services and DNS. Enrollment
through proxie would give me sssd settings I need by default. Without it I would need to
rely on discovery during the enrollment and then reinvent a whell a little bit to drop
priority of the unhealthy SRV targets.
Well now when I wrote it down and think about it once again, maybe it is ok. If we
won't specify exact server for enrollment during ipa-client-install and if I have an
ability to drop down unhealthy SRVs, everything should work fine.
After all I just wanted to test things and compare during functional tests which scheme
would handle problems better in lab environment. And also I just genuinely wanted to
figure out the exact problem to understand the internal ipa interactions better. Because
from my perspective as I understood the theory, everything should work.