Skip to Content.
Sympa Menu

grouper-dev - Re: incremental provisioning theory

Subject: Grouper Developers Forum

List archive

Re: incremental provisioning theory

Chronological Thread 
  • From: Tom Zeller <>
  • To: Grouper Dev <>
  • Subject: Re: incremental provisioning theory
  • Date: Fri, 5 Feb 2010 16:59:56 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=NLknFD8lEYR8u5mDu6KG1L6KbkuW7Ld3EAQIHpUcVudFp7G6oQ5FZsB1m8WWKDXT1c oJd1788ZuD0q4NpLTrV2/4P7K3NoRb7ctnCSS0Kbhc2pbQfK4QiEH1A6y4hZouP/09rM P7ImBgk866uDcj53lJgP/f3+kO/3fA/1aNYa0=

I clicked send to soon. Another option may be to provide a data
connector to the shib attribute resolver which is connected to the
grouper changelog, instead of to the grouper-api. This would avoid
modifying the attribute resolver. Ldappc-ng would need to behave
differently based on whether or not it's provisioning from the
changelog, maybe we handle this with different config files and jvms.


On Fri, Feb 5, 2010 at 4:54 PM, Tom Zeller
> I'm not sure how to provision a subset of a provisioned attribute's values.
> We've been calling this incremental provisioning, likely based on the
> changelog. For example, "add member M to group G field F".
> Ldappc-ng gets the attributes to provision from the shib attribute
> resolver, which is able to calculate a single attribute (and all of
> its values), but not necessarily an attribute and only one of its
> values.
> This is a likely a performance problem for provisioned attributes with
> a large number of values, for example, a group with many members.
> I think it's possible to modify the "data context" passed to the shib
> attribute resolver and its behavior to support this kind of
> provisioning, however I have not attempted to.
> There's more I can say, but I think I should stop here for comments.
> TomZ

Archive powered by MHonArc 2.6.16.

Top of Page