Development Todo list (in no particular order)

This page lists what needs to be done by the new GUMS developer to finish up GUMS 1.4.

  • Recyclable Accounts (see John Hover's email below) - 2 weeks FTE
    Rationale: As more VOS are created, and as VOs have larger numbers of members, a site 
    that wants to support all VOs but not use group accounts must pre-create thousands of 
    UNIX accounts (one for each potential VO member). They are forced to do this even 
    though 99% of these accounts will never be used.
    For sites that are able to dispense with the use of grid-mapfiles, pool accounts go a 
    long way toward lessening this burden. These sites only need to create enough pool 
    accounts to handle users that actually interact with the site. But over time the 
    number of allocated accounts will grow, regardless of whether they are still being 
    used or not.
    Account recycling provides a way to de-allocated pool accounts assigned to a particular 
    Implementation proposal:
    Rather than have GUMS perform any UNIX administration (account group membership, file 
    management, etc.) we propose that GUMS simply provide a way to query for a list of 
    de-allocated UNIX accounts and leave any needed action to site administrators.
    Pool accounts will always be in one of three states: ASSIGNED, SUSPENDED, AVAILABLE. 
    GUMS will track the last time any particular ASSIGNED pool account has been mapped to 
    (i.e. is the result of a mapUser() call). Periodically, GUMS will scan pool accounts to 
    see if any accounts haven't been used for more than a specified amount of time.
    Any accounts found that meet the criteria will be moved to the SUSPENDED state--they are
    now candidates for recycling. If a user who had been given one of these accounts utilizes 
    the site, they will be mapped to another account.
    After a UNIX username has been in the SUSPENDED state for a specified time, it is moved 
    to the AVAILABLE state. It is now a candidate for dynamic mapping again.
    A new call will be provided, String[] getSuspended() which will return a list of all 
    accounts currently in the SUSPENDED state. As long as site administrators use this 
    call more frequently than the amount of time accounts are left in that state, they 
    can be assured of being able to run any necessary cleanup scripts before such accounts 
    are re-used.
    Another new call will be provided setAvailable(String[]) which will allow admins to 
    immediately move UNIX usernames to the AVAILABLE state, if they wish. This could be 
    called after having processed some SUSPENDED accounts, in order to avoid having them 
    appear in the next getSuspended() call.
    New accountPoolMapper parameters and defaults:
    unusedScanCycle   how often to check for unused accounts   1/day
    minUnusedTime     minimum unused time for recycling        1 month
    suspendTime       time to leave in SUSPENDED state         1 week
    -- One advantage of this scheme is that it doesn't *require* any action on the part of 
    site admins. If they don't care about group assignement or file cleanup, they can simply 
    set suspendTime to 0. Idle accounts would then move directly to the AVAILABLE state upon 
    -- EGEE uses recyclable pool accounts and only requires that there be sufficient UNIX 
    accounts created to cover the number of simultaneous different users of a site. However, 
    UNIX accounts are only ever re-allocated to users from the same VO, so file readability 
    is less of a concern.
    -- Any recycling scheme can only be used at a site that no longer generates grid-mapfiles.
    -- Thinking more about this carefully, we realized that most of the UNIX account burden 
    is coming from using grid-mapfiles. Sites that can eliminate grid-mapfiles can basically 
    avoid the bulk of the problem. So perhaps there isn't the urgent need for recyclability 
    that we thought at first. 
  • Figure out JPA/Hibernate error when saving from the web interface - not sure why unit test doesn't catch this - unknown time
  • Create getOutOfDateFqans_form.jsp and getOutOfDateFqans.jsp in gums-service to handle getOutOfDateFqans(int hoursSinceLastUpdate) API method, which should also be added to the GUMS RSV probe so that it gives an error for any FQAN who's users hasn't been updated lately. This was requested by Mine Altunay ( The GUMS RSV probe is at and will require access from Arvind Gopu ( John Hover suggested an entirely different approach, which is to disable a usergroup that hasn't been updated within a certain amount of time. Then, assuming it doesn't show up in the FQAN mapfile, the RSV probe will automatically detect the problem. - 3 day FTE for both GUMS and RSV code
  • Test JSP pages in gums-service thoroughly since the underlying gums-core has been through a lot of changes recently requiring adjustment to the jsp pages - 2 days FTE
  • Add additional unit tests to gums-core as appropriate, particularly for the JPA, which was added for improved ease in making changes - 2 days FTE
  • Try to make output of unit tests cleaner (despite intentional error throwing in the unit tests) - 2 days FTE
  • Create flow chart of GUMS - 2 days FTE
  • Test plugin architecture (any usergroup, accountmapper, or hostToGroupMapping can be put in the classpath and they should be available in the web interface) - 1 day FTE
  • Review and update documentation in gums-site for 1.4, adding information about the new plugin architecture - 3 days FTE
  • Implement in gums-core for storing data within JPA framework (research what already exists)) - 5 days FTE
  • Complete and update in gums-core with John Hover's work - unknown time
  • In in gums-core, replace my DN with yours so you have administrative access during testing. Ultimately though, files in src/main/sql and src/main/scripts need to be updated.