Grouper Developers Forum

["Cramton, James" <>]

Yesterday, Brown released MACE Grouper 1.2.0 into production just in
time for use in the fall semester. It's been a wild ride to get this
far, but we feel very good about where we stand. I'll be presenting
results of our rollout at the upcoming I2 member meeting in San Diego,
but here are some high level observations from our recent release. 

The scope of our initial rollout is limited to course groups--we have
13,700 course groups (12 for each of 1100 courses more or less). The
supported applications for this semester include:

- WebCT student memberships are provisioned out of the LDAP course
groups we've derived from MACE Grouper via ldappc. For logistical and
procedural reasons , we maintained existing support for WebCT. We expect
to manage TAs, instructors, auditors, etc. in WebCT via MACE Grouper
later this term or in the spring term. 

- Confluence now uses a mix of local groups and LDAP course groups, and
it is working as well as Confluence can work with a non-AD LDAP server. 

- iTunes student and administrator provisioning derives from our LDAP
course groups

- Majordomo course groups are derived from our LDAP course groups 
 
Our user base is limited to about half a dozen instructional technology
consultants, so the UI is in limited release for this term.


What we've seen now that we're starting to get some real data is that
any future interface design for MACE Grouper needs to take common use
cases, configurability, and ACLs very seriously. For example, we
disabled the GrouperAll default permission for policy reasons. So this
is what users tend to see on the My Memberships page when they log into
MACE grouper:
 
[] 
[] 
[] 
[] 
[] 
[] 
[COURSE:TEST:0001:2007-Fall:S01: All ] 
[COURSE:TEST:0001:2007-Fall:S01: Learner ] 
[COURSE:TEST:0001:2007-Fall:S01: Student ] 
[SERVICE:MYCONNECTION] 

We have not allowed users to list the group name in the provisioned
groups to which they belong, but the UI presents them as empty strings,
rather than hiding them. For now, we're just having our course
administrators ignore My Memberships, but in time, we want students to
be able to review their memberships, and this kind of display won't work
for that purpose. Maybe there are ACL settings we can use to get these
to display better, but we're afraid of the overhead cost of applying
read ACLs to a lot of users and groups. We continue to find ways to
improve the display while maintaining the security model we have. An
additional concern is that once we introduce both course groups and
community, department, and ad-hoc groups, students may belong to 40 or
50 groups. This presents some real challenges in the UI.
 
We're also getting feedback that without membership in the wheel group,
our course administrators are only able to remove users from a group by
removing the Member privilege, which is not very intuitive. Also, there
are several dead ends in the UI that are confusing our users by
preventing them from easily finding their way back to the group they
were using. The new import/export functionality will need some work
before it's flexible enough to be used by our end users. I  know there
is talk of a project to review the UI requirements. Where does that
stand these days?
 
Over the next week, I will be documenting the issues we're having in
JIRA, complete with screen shots and analysis.

In the mean time, I have some provisioning performance figures to share
as well. It's interesting to note the evolution of our runtime since we
started our deployment in May 2007.  Our initial run of ldap pc died
after a few hours' runtime, having processed a small fraction of the
total groups. Generous contributions of time and gray matter from Tom,
Gary, Blair, and others helped us achieve a remarkable reduction in
runtime.  The current production runtime ranges from 2.5 to 4 hours,
depending on the degree of change in the course feed. Typically, the
sequence looks like this:

90 min: LDAP provisioning from business system feeds (unchanged)

In Parallel:
        10 min: Feed MACE Grouper SQL person registry from LDAP People
        20 min: Business system feed of group data to legacy Brown
Grouper

20 min: Update MACE Grouper groups from Brown Grouper

In Parallel:
        5  min: WebCT user provisioning from LDAP
        20 min: Provision LDAP from MACE Grouper using LDAPpc

3 min: WebCT course membership provisioning from LDAP course groups

Outside the time slot of the nightly provisioning run, we will be
running LDAPpc in a loop to make manual changes from the MACE Grouper
interface available in LDAP in a more or less timely manner. With a 20
minute runtime, this looks promising. But as we introduce our
demographic groups, we expect LDAPpc runtime to increase significantly.
During our QA cycle, we typically saw LDAPpc run in the 3 to 5 hour
range, because we included our demographic groups, many of which contain
13,000 members in the hasMember attribute. This kind of configuration
brings a severe performance penalty that for now, we are avoiding. But
that will necessarily change. We're hoping to change from a batch LDAPpc
methodology to a messaging queue, but in the mean time, we have many
issues to deal with in user training, group schema management, and
policy.

 
James Cramton
Lead Programmer/Analyst
Brown University

401 863-7324