Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: incremental provisioning theory

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: incremental provisioning theory

Chronological Thread 
  • From: Tom Barton <>
  • To: Tom Zeller <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] Re: incremental provisioning theory
  • Date: Mon, 08 Feb 2010 14:35:55 -0600

Or could one data connector access both api and changelog, fabricating appropriate responses from the union of the two?


Tom Zeller wrote:
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

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.


Archive powered by MHonArc 2.6.16.

Top of Page