On Mon, Jan 07, 2019 at 06:01:08PM +0000, R Davies wrote: > On Fri, 4 Jan 2019 at 10:19, Jakub Hrozek <jhro...@redhat.com> wrote: > > > Would the stickiness also persist across SRV priority levels? What I > > mean is that if server1 had originally the highest priority (the lowest > > priority value in the SRV record), but then the SRV record is expired > > and the server is suddendly in a lower priority tier, IMO then the server > > should be 'forgotten' and a new one chosen.. > > > > You're right to highlight this. Different admins may have different > requirements, perhaps the configuration option "ad_sticky" could control > behaviour: > > always - Always sticky, prefer the originally discovered server, unless the > sticky server has been removed from the service record > priority - Mostly sticky, prefer the originally discovered server, unless > its priority in the service record has changed > never - No stickiness (default, and current behaviour), i.e. always > potentially change ldap server on expiry of the ldap connection.
As long as the default behaviour stays the same, I'm fine with just implementing never and always or never and priority. I think it's just important not to prevent extending the code further. > > In terms of implementation, would this be confined to the AD provider or > would IPA also benefit with this? If so, the perhaps it should live > in fail_over_srv.c. I'm a bit unclear as to how this might be implemented > in the fail_over_srv "plugin". The fo_discover_srv_* functions have a > resolv_ctx available to them, but it would seem neater to have a dedicated > fo_discover_ctx structure to store the configuration, along with the sticky > ldap server name. My initial idea was to create a wrapper around resolv_sort_srv_reply() that would take the previous server and optionally a flag parameter. Then, if the previous server was present and the flags would indicate that the server should be preferred, it would just be moved to the 1st place in the list. The previous server would probably have to be kept somewhere in the fail over code, maybe struct fo_ctx could be used? If course, fo_discover_ctx could also be used, did you think about creating it as a member of fo_ctx, maybe created during fo_set_srv_lookup_plugin() ? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
