[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: RFC2589 implementation

This RFC is a bit of a mess.

As I understand it, to create a dynamic entry the client does:
        1) an LDAP add of the entry providing dynamicObject
        as one of the objectClass values.  The entryTTL
        attribute is not to be provided (it's marked
        NO-USER-MODIFICATION).
        2) an LDAP refresh with the name and desired TTL.

Upon 1, the server should install some value for entryTTL.
Upon 2, the server should install some value for the
entryTTL (a value no less than the desired TTL),
returning as the responseTtl.

Interestingly enough, the server could provide 31557600
and just skip all the dynamic deletion stuff.

Now the section 5 text suggests the client should provide
an entryTTL with the AddRequest, but as this attribute
is NO-USER-MODIFICATION, that's not possible. 

Another thing to note is that entryTTL is dsaOperation.
This implies that its value is specific to the DSA
which holds it.  Values of dsaOperation attributes
should not generally be replicated.

While I think it might be better to redesign this
extension (use a client provided deleteObjectTime
attribute, with master providing deletion of the
object at any time after the value of this attribute,
client may modify deleteObjectTime if necessary),
if this specific extension is needed, I think it
should be designed to only require the master to
be dynamic object aware.  This would impart a
requirement that the master be responsible to
not only delete any dynamic object from it, but
ensure same occurs on its slaves... 

Are there clients that are designed to make use
of the RFC2589 extensions?  Do they actually
implement all of client requirements of RFC2589?

Kurt


At 12:08 PM 1/2/2006, Pierangelo Masarati wrote:
>> At 10:24 AM 1/2/2006, Pierangelo Masarati wrote:
>>>> In regards to replication, I suggest that the master produce
>>>> replication events for the deletes and the slaves simply
>>>> act upon these events.  Aside from allowing the use
>>>> non-dynamic-entry-aware slaves,
>
>This is contemplated: if the overlay's state is set to FALSE, it only
>installs support for dynamic objects, but for the rest slapd acts as a
>regular slave; the same applies to a proxy, where the inactive overlay is
>simply used to install handling for the refresh exop.  I think I should
>split the module in two, so that the inactive overlay is not installed at
>all, and only support for refresh is installed; all the rest that's needed
>is to mark the database as SLAPD_DYNAMIC().
>
>>>> it prevents replication
>>>> errors caused by dynamic v. replication event ordering.
>>>
>>>I considered that possibility, but I didn't choose that way because if
>>> the
>>>master crashes the dynamic objects on the slave will never expire.
>>
>> Well, you could write them to the DB.
>
>I do.  I also keep a dynamic structure for the task and so.
>
>>
>>>Another point is that currently when the master shutdowns cleanly, it
>>>deletes all the dynamic objects; if replica dynamic entry deletion is
>>>based on replication, dynamic objects would be prematurely deleted on all
>>>slaves even if only the master was stopped.
>>
>> If you wrote them to the DB, you could delete them on startup
>> (if they have expired).  To accomplish this, I'd use absolute
>> time management internally and just treat the ttl stuff as
>> the client visable interface.
>
>Actually I do the opposite: entries are stored into the database, so that
>regular operations don't need any special handling by the overlay; at
>shutdown, dynamic objects are expunged.  This should also be consistent
>with RFC 2589, as clients must be ready to regenerate the entry if for any
>reason the expire time cannot be honored.
>
>>
>>>I think we can handle this,
>>>though; but in any case slaves must be able to account for dynamic object
>>>expiration on their own; or simply, we shouldn't bother too much about
>>>consistency of replicted dynamic objects.
>>
>> RFC 2589 was supposedly designed such that no harm would
>> come from delayed deletion.  Unforunately, the use of
>> relative TTLs screws this over.  Oh well.
>
>I noted that issue, and in fact I make use of the task's absolute timing
>any time it's required.  To preserve absolute timing I think we need to
>add an operational attribute that contains the expiration time.  Is it
>worth the effort?  And I'm not absolutely sure preserving dynamic objects
>across DSA reboots is consistent with RFC 2589; for sure, it would be a
>nice feature.  However, I'd leave it as an exercise for someone else ;).
>
>p.
>
>
>
>Ing. Pierangelo Masarati
>Responsabile Open Solution
>OpenLDAP Core Team
>
>SysNet s.n.c.
>Via Dossi, 8 - 27100 Pavia - ITALIA
>http://www.sys-net.it
>------------------------------------------
>Office:   +39.02.23998309          
>Mobile:   +39.333.4963172
>Email:    pierangelo.masarati@sys-net.it
>------------------------------------------