On-demand provisioning

[wsanchez@…]

Right now, when provisioning accounts from OpenDirectory, we're periodically polling OD for all of its records. That seems a little rude, and also suboptimal.

Here is what I propose:

The provisioning resources (that is /calendars/* and /principals/*) should do lazy loading of data from OD.

Say a request comes in for /principals/users/wsanchez or /calendars/users/wsanchez:

• If the principal for wsanchez doesn't yet exist (on disk), check OD to see if this is a valid calendar user (ie. has a CalendarPrincipalURI attribute for this server)
  • If yes:
    • Create the principal on disk and cache the relevant data from OD for the principal
    • Record the time
    • Provision a calendar home (/calendars/users/wsanchez)
• If the principal for wsanchez does exist (on disk):
  • If it is stale (for some configurable value, say one hour), reload the cached data from OD and:
    • If the user still exists in OD (same name and GUID), update the cached principal data as appropriate.
    • If the user still exists in OD, but is no longer a valid calendar user, or if the user no longer exists in OD:
      • Archive the user's calendar home
      • Delete the user's principal
      • Return a 404 NOT FOUND response
    • If the user still exists in OD, but has a different GUID
      • Treat that as a deleted user that has been replaced by a new user with the same name:
        • Archive the user's calendar home
        • Delete the user's principal
        • Create the principal on disk and cache the relevant data from OD for the principal
        • Record the time
        • Provision a calendar home (/calendars/users/wsanchez)
• Once you have an up-to-date principal on disk, continue with request processing using that data.

[wsanchez@…]

We now do provisioning in that we don't create resources until they are needed, though we still ask the directory for all records at once.

If an account goes away, it is no longer accessible. We may still need to add a test case for this.

If an account that has gone away comes back, it was still there under the covers and access is re-established with no data loss. Another test case to add...

What we don't do yet deal with a new account which replaces an existing one (new GUID).

[wsanchez@…]

De-provisioning is now #111, so we're done here.

[wsanchez@…]

Milestone Preview 1 deleted