[Freeipa-devel] IPA ldap-updater improvements

Martin Kosek mkosek at redhat.com
Fri Dec 12 12:46:59 UTC 2014


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.




More information about the Freeipa-devel mailing list