-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAk2oCw8ACgkQHsardTLnvCUoVACfSc87C0upEddcjiJ33PTEtjCT
idAAn08Z2Gz7yUDCEE9Vrt7I7s07gQC8
=erEY
-----END PGP SIGNATURE-----