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 
  user.
  
  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
  
  Notes:
  -- 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 
  recycling.
  -- 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 (maltunay@fnal.gov). The GUMS RSV probe is at https://osg-svn.rtinfo.indiana.edu/rsv/trunk/ and will require access from Arvind Gopu (agopu@indiana.edu). 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 LdapPersistenceEngine.java in gums-core for storing data within JPA framework (research what already exists)) - 5 days FTE
• Complete and update URIToolkit.java in gums-core with John Hover's work - unknown time
• In HibernatePersistenceEngine.java 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.