Only allow one fixup task at a time

[mreynolds389]

Issue Description

We keep seeing issues where customers incorrectly create 100's or 1000's of memberOf fixup tasks which leads to overall terrible server performance. We should only allow one fixup task per plugin.

[mreynolds389]

198d921..fc205ec 389-ds-base-2.2 -> 389-ds-base-2.2
814f8b5..d1b1678 389-ds-base-2.1 -> 389-ds-base-2.1
6083fd1..4401b66 389-ds-base-2.0 -> 389-ds-base-2.0
e665ae0..5dd7043 389-ds-base-1.4.3 -> 389-ds-base-1.4.3

[tbordaz]

The detection of concurrent memberof task should be done consider base/filter.
IPA is doing valid parallel fixup tasks

dn: cn=Update PBAC memberOf $TIME, cn=memberof task, cn=tasks, cn=config
objectClass: top
objectClass: extensibleObject
cn: IPA PBAC memberOf $TIME
basedn: cn=privileges,cn=pbac,$SUFFIX
filter: (objectclass=*)
ttl: 10

dn: cn=Update Role memberOf $TIME, cn=memberof task, cn=tasks, cn=config
objectClass: top
objectClass: extensibleObject
cn: Update Role memberOf $TIME
basedn: cn=roles,cn=accounts,$SUFFIX
filter: (objectclass=*)
ttl: 10

[Firstyear]

This may not be true @tbordaz because IPA has nested groups. so you could have cn=some_priv,cn=privileges,cn=pbac,$SUFFIX which includes a member cn=myrole,cn=roles,cn=accounts,$SUFFIX. Since these are nested, this would trigger the members of cn=myrole to be adjusted too. Since there is also the second fixup in update role, it could conflict on the changes and cause loss of member of records.

I think that nested groups pretty much means you have to consider only one memberof fixup at a time.

[tbordaz]

I absolutely agree with your point. With nested groups it is unpredictable if parallel fixup will or not steps on each other. In addition I would say that parallel fixup will increase DB pressure (even if accessing different entries) with a higher risk of retries so from performance pov, there is a possibility that parallel fixups will take more time that serialized one.

Now IMHO it should be in the hand of the administrators/applications to decide/experiment if parallel fixups bring some benefits.

This ticket was initially created because of an administrator launched multiple times by mistake the exact same fixup. So I would rather see this ticket to prevent same base/filter tasks.

[mreynolds389]

Well the real issue I was trying to prevent was allowing "identical" tasks to be run at the same time. But there are legitimate cases where you might want to run fixup tasks on two different branches. Refining fix...

[mreynolds389]

216c14d..1091ca9 389-ds-base-2.2 -> 389-ds-base-2.2
36e32f4..9d086f4 389-ds-base-2.1 -> 389-ds-base-2.1
959d36e..70e0175 389-ds-base-2.0 -> 389-ds-base-2.0
08ce159..90a8319 389-ds-base-1.4.3 -> 389-ds-base-1.4.3