On 12/12/2014 10:38 AM, Martin Basti wrote:
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.
Makes sense to me, better determinism should help us avoid the problems we had
with 4.1 upgrades. CCing Rob for reference.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
