[midPoint] HA: HA: HA: Prohibit having particular assignments

[Pavol Mederly]

Hello Алексей,

I've studied the logs you've sent here.

Look at the line 9182, just after the text "2015-05-26 12:46:50,285 
TRACE: Evaluating hook 'Example scripting hook'".

You see that "User old" and "User current" have all the assignments, namely:

             assignment:
               id=2
                 targetRef: 
oid=5e8b8660-a788-4b7c-8a6c-f08f3ff3d4a1(RoleType)
               id=3
                 targetRef: 
oid=7faa8e52-d8d8-487f-8a25-987a0eaf4521(RoleType)
               id=4
                 targetRef: 
oid=cdb06bb4-c134-4ce5-b0f9-483b32832114(RoleType)
               id=5
                 targetRef: 
oid=3427d715-52a1-4806-9f81-0304f57ffb90(RoleType)
               id=1
                 targetRef: 
oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)

and "User new" does not have them. So far so good.

BUT.

The secondary delta(s) do not contain the delta that caused that removal:

      User secondary delta:
         ObjectDeltaWaves:2 waves
           wave 0:
ObjectDelta<UserType>(UserType:1e0a1255-9a03-415f-9bef-1ea5d4d4bbd8,MODIFY):
               extension/hrStatus
                 REPLACE: REJ
               assignment
                 ADD:
                   id=null
                     targetRef: 
oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
                 DELETE:
                   id=null
                     targetRef: 
oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
               activation/administrativeStatus
                 REPLACE: DISABLED
               parentOrgRef
                 ADD: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
                 DELETE: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
           wave 1:
ObjectDelta<UserType>(UserType:1e0a1255-9a03-415f-9bef-1ea5d4d4bbd8,MODIFY):
               extension/hrStatus
                 REPLACE: REJ
               activation/effectiveStatus
                 REPLACE: DISABLED
               activation/disableTimestamp
                 REPLACE: 2015-05-26T12:46:45.745+03:00
               parentOrgRef
                 ADD: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
                 DELETE: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)

And the deltas are what counts. ChangeExecutor executes deltas, not the 
"User new" state. The "User new" state is dynamically recomputed (using 
deltas), at many places.

I'm refering to this code:

result = new OperationResult("get_object_by_oid");
task = taskManager.createTaskInstance("get_user_by_oid");
focus.assignment.removeAll(rolesToDelete);
current = modelController.getObject(UserType.class, focus.oid, null, 
task, result);
delta = current.diff(focus.asPrismObject(), true, true);
context.engineScope.get("modelContext").focusContext.addSecondaryDelta(delta)

So, I have two recommendation:
1) Do not call removeAll(rolesToDelete) on live object from the model 
context. Use a clone instead.
2) Try to find why the computed deltas are not incorporated in the context.

As for 2, I would recommend putting some kind of logging to make sure 
the delta is computed well.
In particular, I would replace current.diff(focus.asPrismObject(), true, 
true) by
current.diff(focus.asPrismObject()).But that does not seem like the cause.

There's probably one more caveat - not showing in your particular case, 
but still present.
If you put something into secondary delta, there's a risk that these 
deltas will get recomputed
if clockwork would think that the context is not fresh - around lines 
236-241 of Clockwork:

if(!context.isFresh()) {
    context.cleanup();
    projector.project(context,"PROJECTOR ("+state+")", task, result);
}else{
    LOGGER.trace("Skipping projection because the context is fresh");
}

Note that the projector.project simply re-computes secondary deltas from 
the beginning (i.e. from the primary delta). I'm not sure how to work 
around this. (Rado? Have you any idea?) Maybe modifying the primary 
delta instead of secondary one? Or just hoping this situation would not 
occur? :)

Anyway, if I find a little bit more time, I could play for a while with 
this. Until that, you could consider modifying your code according to 
the recommendations above.

Regards,
Pavol

On 26. 5. 2015 11:59, Алексей Ващенков wrote:
> Send the log in attachment
> ________________________________________
> От: midPoint [midpoint-bounces at lists.evolveum.com] от имени Pavol Mederly [pavol.mederly at gmail.com]
> Отправлено: 26 мая 2015 г. 12:38
> Кому: midpoint at lists.evolveum.com
> Тема: Re: [midPoint] HA:  HA:  Prohibit having particular assignments
>
> I think this thread https://lists.evolveum.com/pipermail/midpoint/2015-May/000995.html would be a better place to discuss this issue because the initial problem is rooted there.
>
> OK, so continuing here.
>
>
> System configuration is in attachments. How properly setup logs? If I enable model logger to debug, then each time hook is fired logs increase by 6MB
>
> Yes, model diagnostic is quite verbose. Anyway, I suggest the following:
>
>        <classLogger>
>           <level>TRACE</level>
>           <package>com.evolveum.midpoint.model.impl.lens.Clockwork</package>
>        </classLogger>
>        <classLogger>
>           <level>TRACE</level>
>           <package>com.evolveum.midpoint.model.impl.lens.projector.Projector</package>
>        </classLogger>
>
> ...and remove the DEBUG placed at the level of model, i.e. this one:
>
>        <classLogger>
>           <level>DEBUG</level>
>           <package>com.evolveum.midpoint.model</package>
>           <appender>IDM-PROFILE_LOG</appender>
>        </classLogger>
>
> I really suspect that the secondary deltas get recomputed during the process.
>
> Pavol
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150526/d443f150/attachment.htm>