Revisit Account Management (Prometheus) - Final Report

History, Plan, etc.

The devproj page - http://devproj.inf.ed.ac.uk/show/75 - shows the history, original plan and details of milestones. During the later stages of the project itself, a wiki page (https://wiki.inf.ed.ac.uk/DICE/PrometheusTodo) was used to track progress of the various elements (this is out of date now). The main prometheus documentation gathers together various relevant documents: https://wiki.inf.ed.ac.uk/DICE/PrometheusOverview

Development

Simon wrote the original Account Musings document in September 2007 and this was then discussed at a development meeting in November 2007.

Serious development work began in Spring 2009. Simon wrote the original framework and Simon and Toby then collaborated on the rest of the prometheus code. Craig and Simon worked on the AFS stores and conduits. Most development subsequent to prometheus being rolled out has been done by Toby.

The prometheus system went live in time for the new student intake in August 2010.

The bulk of the main project work was completed by the end of 2011, although there has been continued prometheus development since then, much of which has been bundled in with this project, where no other projects exist. Project completion has been stalled on delivery of AFS test suites (project #164 http://devproj.inf.ed.ac.uk/project/show/164).

Notable Successes

Since August 2010, all of our new accounts are now provisioned automatically (this includes creating KDC and AFS pts entries, populating LDAP (rfc2307) and allocating and creating AFS vldb entries in the appropriate locations, mailing students about their new accounts, allowing passwords to be set via a web form, or generated by support staff).

The Prometheus API gives us a consistent programmatical way to manage all aspects of our accounts, e.g. when we needed to disable accounts pending a password change in 2011, we did this using Prometheus. Tools provide a consistent way of communicating with prometheus and its data stores.

Prometheus auditing produces reports which detail inaccuracies and inconsistencies in data. This has proved useful in cleaning up our data.

The Prometheus code is highly extendable.

Code review - we introduced our git/gerrit code review system as a byproduct of prometheus development. This proved invaluable and has now become a proper supported service.

Notable Problems

Prometheus is quite a large piece of work - the code base comprises approximately 35000 lines of code. Some of the code, particularly in the internal framework, is quite complex and requires an understanding of the Moose meta object protocol. Moose itself (a perl OO framework) can represent quite a steep learning curve. Prometheus replaced a diverse and wide-ranging series of scripts and procedures that have developed over many years, in different places. All of this is to say that the project was enormous in both scope and work required and should probably have been split into sub-projects to be more effectively managed. It seems clear that the amount of work required was massively underestimated.

Communication was a problem at some stages of the project, with the unavailability (sometimes unexpectedly) of key members of the development team causing difficulties and delays. This is perhaps a function of collaborative development with people who are not full-time University employees and not based on University premises.

As a result of a combined disk and backups failure, code which would implement account lifeycle was lost. This subsequently had to be completely rewritten (see http://devproj.inf.ed.ac.uk/show/262).

The interface with the school database is problematic in a couple of areas - the 2g/3g split and the different approach to different categories of staff (e.g. visitors disappear, other staff don't). The former problem will resolve over time (as all data moves to 3g), the latter should be addressed by formally defining the interface between the DB and prometheus.

One of the original intentions was that prometheus code (stores and conduits) could be contributed from across the C[S]O community. This hasn't really happened.

Future Work

Implementation of lifecycle code (http://devproj.inf.ed.ac.uk/show/262) will make managing the entire account lifecycle (e.g. account archiving and deletion) much easier than at present.

Support for multiple identities is built into the prometheus data model, but isn't really used at present. Work which brings the strands together to make this genuinely useful is ongoing.

IS developments may impact on prometheus. e.g. IDMS developments, changes to EASE service (see http://devproj.inf.ed.ac.uk/show/260 and https://www.dice.inf.ed.ac.uk/units/infrastructure/Projects/260-MIT-kerberos-alternatives/ProsAndCons.html). In particular, if we move to using EASE authentication instead of managing our own KDC, there will be significant implications for Prometheus and many other aspects of account management.

Speeding up some aspects of prometheus conduits is desirable and should be possible.

Prometheus needs to be ported to work with Moose 2. Changes have been made to Moose internals which will require changes in Prometheus's core. This will probably be bundled into SL7 work.

Prometheus heavily uses our roles and entitlements (also known as roles and capabilities) system. This was somewhat revamped with the Review Roles mechanisms project (https://devproj.inf.ed.ac.uk/show/197). However, we would like to do some further tidying of our roles sructure.

Time Spent

(These figures represent all time spent on Prometheus since the project's inception, other than that accounted for in other projects)

Toby: 1391.75 hours (~40 weeks) Simon: Craig:

Links

The main prometheus documentation is here.

https://wiki.inf.ed.ac.uk/DICE/PrometheusOverview

-- TobyBlake - 31 Mar 2014