Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "VT VAPOR:VAPOR OpsPortal Engage"

From EGIWiki
Jump to navigation Jump to search
Line 2: Line 2:


The User Database implemented in the Operations Portal retrieves user information from the VOMS servers. It is proposed to extend this database as a tool dedicated to VO managers, to store user information besides the administrative data available in the VOMS. Three main goals are identified:
The User Database implemented in the Operations Portal retrieves user information from the VOMS servers. It is proposed to extend this database as a tool dedicated to VO managers, to store user information besides the administrative data available in the VOMS. Three main goals are identified:
* Manage and follow up on users registration life-cycle: registration (VO membership), group membership, membership expiration. The life cycle workflow integrates interactions with third party services such as the VOMS, file catalog, EGI Applications Database.
* Manage and follow up on users registration life-cycle. The life cycle workflow integrates interactions with third party services such as the VOMS, file catalog, EGI Applications Database.
* Track information about users "hidden behind" a robot certificate, in order to have a realistic idea of the number of actual users in a VO.
* Track information about users "hidden behind" a robot certificate, in order to have a realistic idea of the number of actual users in a VO.
* (Track information about scientific publications to encourage users to acknowledge the usage of EGI resources).
* (Track information about scientific publications to encourage users to acknowledge the usage of EGI resources).
Line 9: Line 9:


The User Database should store a least the following information:
The User Database should store a least the following information:
* Administrative data (DN, email, affiliation, membership duration...).
* Administrative data (DN, email, affiliation, VO membership, group membership.
* Free text field: VO administrators must be able to add free text information regarding user's research field, scientific collaborations, etc.  
* Free text field: VO administrators must be able to add free text information regarding user's research field, scientific collaborations, etc.  
* Research discipline classification referring to the [https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification VT Scientific Discipline Classification].
* Research discipline classification referring to the [https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification VT Scientific Discipline Classification].

Revision as of 16:00, 17 July 2014

User community management

The User Database implemented in the Operations Portal retrieves user information from the VOMS servers. It is proposed to extend this database as a tool dedicated to VO managers, to store user information besides the administrative data available in the VOMS. Three main goals are identified:

  • Manage and follow up on users registration life-cycle. The life cycle workflow integrates interactions with third party services such as the VOMS, file catalog, EGI Applications Database.
  • Track information about users "hidden behind" a robot certificate, in order to have a realistic idea of the number of actual users in a VO.
  • (Track information about scientific publications to encourage users to acknowledge the usage of EGI resources).

Users database

The User Database should store a least the following information:

  • Administrative data (DN, email, affiliation, VO membership, group membership.
  • Free text field: VO administrators must be able to add free text information regarding user's research field, scientific collaborations, etc.
  • Research discipline classification referring to the VT Scientific Discipline Classification.
  • Scientific publications: keep track of published works using the infrastructure.
  • DN of robot certificate (if any): users behind a robot certificate may or may not have their own certificate. If they do not, it is important to be able to register them in the database anyway.
  • Scientific application used (linked with the EGI Applications Database)
  • User File Catalog instance (if any) and base directory.

Several collaborations may be considered there:

Periodically, robot certificate holders must be asked to enter information about real users in the system: at least a number of users, at most individual data (email, etc.). Exact content of this information is to be detailed with robot users.

User life cycle management

Currently, a new user registers on the VOMS of the VO he/she wishes to join. Then, the VOMS sends an email notification to the VO administrator who may ask the user to provide additional details about his/her activity and affiliation. Then, the VO administrator manually approves the request.

The goal is to keep the VOMS as the service to initiate the subscription of a user. The features below automate the management of subscription requests received from the VOMS:

  • Registration: filter emails notifications sent by the VOMS to the VO administrators (no other API seems to be available that would e.g. allow application to register with VOMS notifications).
    • Check the validity of the user's DN: no quotes or double-quotes allowed as they are not supported by some services in the infrastructure. In this case, automatically reply and ask the user to require a new certificate.
    • Automatically send an email asking the user to provide details about his activity and affiliation, the applications they use (pointer to the EGI Applications Database).
    • Display a list of pending subscriptions that the administrator can manually approve or reject. The action of the administrator is reflected on the VOMS server.
    • Automatically create the user's root directory in the LCG File Catalog (LFC) with appropriate ACLs. ACLS may be manually relaxed later depending on user's needs.
    • Link user with the existing applications that they use in the EGI Applications Database.
    • Add user's email address to VO users mailing lists the VO users mailing list.
  • Membership expiration: filter email notifications sent by the VOMS, and trigger
    • the cleaning up of files of expired users after a grace period (see Data Management features),
    • the removal of the user's email address from the VO users mailing list.
  • Mailing list management:
    • The integration with different mailing list systems should be studied starting with Mailman and GoogleGroups, to keep a mailing list in sync with the current list of users.
    • An function must allow to simply export the list of email addresses of the VO users.

Optional additional features:

  • Show a summary of the activity on the VO management mailing list: filter out VOMS email notifications that are already taken care of, and display other messages so that someone deals with them.
  • Collect feedback on the infrastructure, and scientific production (publications). For this purposes different alternatives may be considered:
    • Use an existing platform such as Google Schoolar or ResearchGate, and add the publications from the members of the VO after requesting their consent to a specific join profile. This will create H-index factors immediately and it can be easily referenced and shared.
    • Create a database with the entries in different databases and directly link to them. This will be more tedious but less prone to issues due to changes on the interfaces or procedures in the third party tools.