[Date Prev][Date Next]
Re: back-config delete support (syncprov overlay)
Am Freitag 26 Februar 2010 13:30:55 schrieb email@example.com:
Returning an error just for the LDAPSync related Search seemed more
logical to me.
In any case, (ab)using an existing error code might not be optimal. as
consequence of removing slapo-syncprov(5), any consumer using it needs
be clearly informed that just retrying later is probably not an option.
On the contrary, returning a dedicated error would allow to exactly
the consumer about what it can expect from the (former) producer, and
possibly to suggest a strategy (e.g. the message could contain a hint
about some substitute producer, or so).
This situation is no different than pointing a consumer at a server that
no provider configured. We don't do anything special for that case; I
believe anything special is called for here.
Well, I believe it's not exactly identical. If you point a consumer to a
DSA that's not a producer, sync replication cannot initiate. If you point
a consumer to a DSA that's a producer, and eventually ceases to be a
producer, the consumer could take advantage of being informed that it's
pointless to keep retrying an "unwilling to perform" that could be
interpreted as a temporary failure. But I don't want to make a point of
it, as it would probably take us too far from the initial objective...
The actual sequence of events would be: consumer receives LDAP_UNAVAILABLE
result on its psearch, then the next time it retries, it will be talking to a
server with no provider. I.e., identical to the never-configured case, it will
receive a search response with no sync control. There is no opportunity to
provide more meaningful diagnostics, nor is there actually anything more
useful that can be said. The situation might be temporary, or it might be
permanent. Who can say?
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/