[Freeipa-devel] Order of updates

[Martin Kosek]

On 04/05/2013 10:38 PM, Rob Crittenden wrote:
> We've had a few problems with permissions come up over the last couple of
> months and I finally sat down to identify what the problem is (this can be seen
> sometimes where some unit tests fail).
> 
> We do some membership manipulation in the updates and there is a task which
> should fix up memberOf. The problem is that that the updates get added AFTER
> the update is executed because of the way the sorting is done.

BTW why the MemberOf plugin does not fix the memberOfs? It should be alreaduy
configured in the update time, so it should just properly generate memberOf
data - or am I wrong?

> 
> There isn't an easy way to make the task DN deeper (I tried), so we need
> something a bit more clever.
> 
> My ideas include:
> 
> - Changing 55-pbacmemberof.update into a POST update plugin
> - Modifying the way update files are loaded so we apply them in blocks, say
> 0-89 are all applied, then 90-* are applied.
> - Adding a new update subdirectory which is applied after the main updates.
> 
> I'm favoring #2 right now but suspect it could get confusing.
> 
> This is ticket https://fedorahosted.org/freeipa/ticket/3377
> 

#2 sounds acceptable, we would just need to clearly communicate what we do
(maybe in man pages too).

Actually, I now came across the updates README (shame on me, this is the first
time I read it), maybe we should re-shuffle our updates file naming a bit
according a schema we define in the README.

Just curious - does the order of updates even still make sense order-wise since
we reorder the updates anyway based on number of RDNs in their DNs?

But I agree that we can reserve a range 90-99 for POST updates and process it
separately in ipa-ldap-updater so that they are run after all other updates...

Martin