Realizing project lifecycle and integrating with project consumers
Apologies for the nondescript title, this is the best I could come up with.
Right now, our project lifecycle looks as follows:
- a project is created in JARDS
- the project PI logs into RegApp, triggering the
AttributeSourceProjectCreaterandAttributeSourceProjectUpdaterbeans. This creates the project in RegApp if not already present, and updates the PI / project admin list. - the project is manually provisioned in the HPC system
- the PI adds members to the project
- the users can begin using the project
The issue we are facing is that provisioning the project in the HPC system is a manual process. This currently cannot be automated because in our system, a HPC project needs to be tied to an existing PI HPC account, and this HPC account name is not known on the JARDS side, nor is it present until the PI has registered for the HPC service in RegApp.
Since the specific data formats exposed in JARDS, and the process of "HPC project provisioning" will always be site specific, we won't be able to provide a "one size fits all" solution, but I think that with some changes / additions, we can get to a point where site integration amounts to just a few nashorn scripts or job classes.
This is what I'm thinking of right now:
- Add a generic job class for retrieving project information from an attribute source, and updating the list of projects and their admins accordingly. The specific format exposed by the attribute source will usually be site specific, but perhaps we can reduce the "site specific AS format to generic these-projects-exist-with-these-PIs" conversion to a per-site nashorn script or helper class.
- Add
PROJECT_ADMIN_ADDandPROJECT_ADMIN_REMOVEevents (and perhaps alsoPROJECT_MEMBERLIST_CHANGEandPROJECT_ADMINLIST_CHANGEso that we can do batched operations?) - Add a job class that will be triggered on these events, which will send a ssh command with the updated member list. The command invocation / parameters could be customized via nashorn scripts. In our case, it essentially dumbs down to
ssh user@host register_project --admins admin1,admin2,...
Alternatively, I suppose we could also poll for project admin changes from the HPC side if the RegApp were to expose this via LDAP attributes.
In any case, we would like to get away from the manual "PI needs to inform us when he has finally registered in the RegApp" step.