Grouper Developers Forum

[Chris Hyzer <>]

It is possible to make it an option, and you can decide what to default it to?
I would think if people have a problem with one way or the other they might 
like the possibility of changing it :)

Tradeoff:

- renaming a stem (something that happens <1% of the time)
vs.
- realtime being delayed by some time (~30 minutes?  depends on deployment?)

I would think incremental should focus on incremental by default and if there 
is something infrequent not handled, it can wait until the end of the day, so 
I would tend to vote on defaulting this to off, and people can configure the 
other way if they like (especially for small deployments where the penalty is 
not that big).  But its not a huge deal if people disagree and it is 
changeable :)

I wonder if it would be terrible if the full sync during the day happened at 
the same time as the incremental (best of both worlds), then the one at the 
end of the day happens while the incremental is stopped.  Or would errors 
ensue?  :)

Thanks,
Chris
________________________________________
From: 

 
[]
 on behalf of Tom Zeller 
[]
Sent: Friday, November 04, 2011 12:52 PM
To: Chris Hyzer
Cc: Grouper Dev
Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming stems 
with child groups ?

> What are examples of these cases?

For now, anything changing the name of a non-empty stem. So stem
rename and move, although copy might be ok. There may be other
ChangeLogTypeBuiltin events, but I have not got that far yet.

>I don't really like the idea since it kills the realtime for ~30 minutes, 
>right?

Depends on the deployment.

> Is this fixing an edge case where we should really just say "if you create 
> a group, and delete it, and create it again, and rename it, in less than 1 
> minute (or whatever causes this), that you can wait until the end of the 
> day"?  Or is there a way to do a partial full sync (e.g. sync a group or a 
> folder fully, but not the whole repository?)

Do we consider stem rename or move an edge case ?

As of now, no, we do not have the ability to full-sync a branch of a
grouper tree, e.g. full-sync from a given stem and below. I am ok with
trying to implement a partial-full-sync or whatever, but it would take
some time to think it through.

TomZ

> Thanks,
> Chris
>
>
>
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom Zeller
> Sent: Friday, November 04, 2011 10:49 AM
> To: Grouper Dev
> Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming 
> stems with child groups ?
>
> So, in general, I am thinking that a possible approach is to perform a
> full-sync whenever the ldappcng change log consumer encounters a
> change log entry that it can not provision incrementally. Otherwise,
> there may be a variety of errors until a full-sync is run.
>
> Thoughts ?
>
> On Thu, Nov 3, 2011 at 12:30 PM, Shilen Patel 
> <>
>  wrote:
>> The original ordering issue you mentioned is resolved now by the way.
>>
>> Thanks!
>>
>> -- Shilen
>>
>> On 11/3/11 1:20 PM, "Chris Hyzer" 
>> <>
>>  wrote:
>>
>>>Sounds good to me, if that's the way we go, lets open a jira for it for
>>>2.2
>>>
>>>-----Original Message-----
>>>From: 
>>>
>>> 
>>>[mailto:]
>>> On Behalf Of Tom
>>>Zeller
>>>Sent: Thursday, November 03, 2011 12:31 PM
>>>To: Grouper Dev
>>>Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming
>>>stems with child groups ?
>>>
>>>So, how should we handle provisioning a renamed stem to ldap via the
>>>change log ?
>>>
>>>Some (maybe most) ldap servers only allow non-leaf objects to be renamed.
>>>
>>>When renaming a stem with child stems and groups, we would need to
>>>create the new stem structure, move groups via renaming, and then
>>>delete the old stem structure. I would categorize this as non-trivial.
>>>
>>>My suggestion for 2.1 is that we say we do not support renaming
>>>non-empty stems via the change log. A full-sync will create new
>>>objects and delete old ones, rather than renaming or moving.
>>>
>>>Thoughts ?
>>>
>>>TomZ
>>>
>>>> Before you get too far, a quick check against my local openldap
>>>> reminds me that some directory servers support subtree renaming, and
>>>> others may not.
>>>>
>>>> For example, given
>>>>
>>>>  ou=stem,dc=edu
>>>>   ou=child,ou=stem,dc=edu
>>>>
>>>> I cannot moddn ou=stem since it is non-leaf. And I cannot rename
>>>> ou=child first since the parent does not exist yet. I would need to
>>>> create a new ou=newStem, move ou=child over to it, then delete
>>>> ou=stem. Which would not be renaming. I guess we care about renaming
>>>> stems for Active Directory since access privileges may be assigned to
>>>> ous, not sure.
>>>>
>>>> Hmm.
>>>>
>>>> On Wed, Nov 2, 2011 at 8:08 AM, Shilen Patel 
>>>> <>
>>>>  wrote:
>>>>> I think the ordering is inconsistent.  I'll fix this to make the stems
>>>>> come before the child objects.  Let me know if anybody is expecting the
>>>>> opposite order.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- Shilen
>>>>>
>>>>> On 11/1/11 7:48 PM, "Tom Zeller" 
>>>>> <>
>>>>>  wrote:
>>>>>
>>>>>>When a stem containing child groups is renamed via
>>>>>>setExtension("newExtension"), the change log entries for group renames
>>>>>>occur before the stem rename.
>>>>>>
>>>>>>This makes it difficult to rename child groups on a target ldap
>>>>>>directory, since the renamed stem (i.e. the OU) has not been renamed
>>>>>>yet.
>>>>>>
>>>>>>Is it possible to change the change log order ? maybe configurably ?
>>>>>>
>>>>>>Otherwise, I would need to gather all change log events for the stem
>>>>>>rename context id, and reorder them somehow, shudder.
>>
>>
>