-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/15/2011 08:42 AM, Stephen Gallagher wrote:
On 04/15/2011 05:08 AM, Jakub Hrozek wrote:
> On 04/14/2011 07:54 PM, Stephen Gallagher wrote:
>> On 04/11/2011 04:36 PM, Jakub Hrozek wrote:
>>> On 04/11/2011 06:07 PM, Stephen Gallagher wrote:
>>>>
>>>> Nack.
>>>>
>>>> While it's not as if we call this function often, it seems
>>>> counter-intuitive to me that we'd be looping through all the server
>>>> lists (which could be arbitrarily long, if we're using SRV records)
on
>>>> every state update, rather than just eating this cost once when adding
>>>> new servers to the list.
>>>>
>>>> In other words, we should do a duplicate check before calling
>>>> create_fo_server() and skip creating it if the name and port matches.
>>>>
>>> I actually think it is more convenient to allow duplicates than to
>>> detect them on create_fo_server() time and disallow them. Let me explain:
>>> It is quite possible (and actually the default for ipa-client-install)
>>> to have the same server name as a result of a SRV query and a hard coded
>>> hostname. The problem is the ordering of servers.
>>> Consider that srv query resolves to "ldap.example.com,
>>> ldap2.example.com" and the config file contains "_srv_,
>>> ldap.example.com". If we discard duplicates after the SRV query is
>>> resolved, the order would be "ldap2.example.com, ldap.example.com"
which
>>> is wrong.
>> Why would that be the order? Wouldn't it be simplest to just check the
>> list before adding each entry, and if it already exists, just not add it?
>> The result then would be
ldap.example.com,
ldap2.example.com (because
>> the attempt to add the hard-coded name after the _SRV_ processing would
>> be ignored since it's already present (and appropriately ordered).
> Right, the problem is that this is done dynamically and the SRV lookups
> can expire, which means that if you skip adding a hardcoded name, you
> need to add it back at the right place when the SRV query expires.
> It's not impossible, it just seemed like a lot of work for a little gain
> -- and actually if we gown down this route, I would prefer skipping the
> duplicate that was resolved from SRV query and place the hardcoded
> "original" there.
You've convinced me. I think your original patch is probably the most
sensible. Ack.
Patch 0002 pushed to master.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAk2oZpMACgkQeiVVYja6o6MsMQCeNqJ7ESz1PFDIq2M9pH8aagwl
/cwAn3yn9vv8r8Ku/i1SW3HPKpP8KWF6
=kevB
-----END PGP SIGNATURE-----