Hello,
I would like to discuss following list of *ldap-updater characteristics*:
1. Updates sorting are based on length of DN, update with shorter DN is
executed earlier
2. DNs of update entries are stored in dictionary
3. update files are parsed in batches 10-19, 20-29, ..., 80-89
*
**Issues**:*
1. This approach solves parent-children dependency issues, but currently
we have dependencies between different branches of tree, required by
plugins, it happens several times for me that shorter DN depends on
longer DN, and DS rejects update.
2. This disallow to specify order of upgrades per file, for example,
update entries A and B have the same length of DN, but B depends on A.
However python internally (may) change order in dict which causes The B
update is executed first and update failed. Solution now is move B to
the file in next update batch. The ticket
https://fedorahosted.org/freeipa/ticket/4680 hits this problem.
3. This granularity seems to be not enough to me, it causes the more
updates are mixed by applying 1. and 2. for more update entries.
*Solutions:*
1. Don't sort DN, developer should be responsible for order of updates.
2. Use ordered dictionary, developer should be responsible for order of
updates per file.
3. Parse files in batches per number, 10, 11, 12, ..., 89
*Summary:*
IMO the ipa ldap-updater does to much magic with updates, would be
better if the updater delegates those responsibilities to developers.
With current state we would hit the issues above more frequently as the
we increase the amount of updates in each release.
As first I suggest to fix 3., which is quite easy and it will decrease
effects of 1. and 2., and allows to use better granularity with upgrades.
Martin^2
--
Martin Basti
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
