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. _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
