[389-devel] USN Design Document

[Noriko Hosoi]

Thank you so much for your comments and suggestions, Andrey!  Some look 
easy (e.g., the first item -- I'm turning it on and run more tests), and 
some look more challenging.  I'm going to make a ToDo section in the 
wiki page and add your list to the section.

Thanks, again.
--noriko

Andrey Ivanov wrote:
> I've seen some changes in the USN design document, so i'll add my two
> cents. Overall it's well written, the architecture seems to be rather
> robust.  There are some scenarious that are interesting for us as for
> the behaviour of the usn plugin and some questions/reflections :
>
> * The USNs seem to be unique within a suffix/backend. Should we enable
> the uniqueness plug-in for them? If not can we be sure that a manual
> change of entryUSN will not interfere with the correct functioning of
> the plug-in?
> * When the plug-in is activated no entry has entryUSN or maybe some
> entries do already have it in some desorder. Maybe we should
> initialise (while plug-in in started for the VERY first time) all the
> entries without entryUSN with entryUSN=-1 or smth like that?
> * Maybe it's a good idea to desactivate the replication of entryUSN
> attribute during the server installation by default?
> * When we do an export with a utility like db2ldif.pl - should the
> entryUSN attributes be exported or not?
> * What happens during the import of a whole ldif subtree by smth like
> "ldif2db -n userRoot -i /tmp/current_prod_database.ldif"  if the
> entryUSNs are already present in the imported ldif? If they are not
> present? if they are present only in a part of the entries?
> * Should usn-tombstone-cleanup be integrated in the server core with
> the thread purging the tombstones ot not? Should it be configurable bo
> some attributes like nsds5ReplicaPurgeDelay and
> nsds5ReplicaTombstonePurgeInterval?
>
> And thank you for your work!
>
> --
> 389-devel mailing list
> 389-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20090718/27bd87f0/attachment.bin>