Task Force (TF) meeting of 2004-11-29

Participants:
Maria Dimou, Joni Hahkala, Dave Kelsey (on the telephone), Tanya Levshina (on the telephone), Karoly Lorentey, Ian Neilson, Valerio Venturi, John Weigand (on the telephone).

Agenda: Approved in advance via email:


Agreed agenda items:
====================
1. Brief Valerio, Vincenzo,John about the TF's mandate and actions so far 
   http://cern.ch/dimou/lcg/registrar/TF/MANDATE
                Ian

2. Open questions from ORGDB (DateOfBirth (DOB), Participation_End_Date,etc)
   Tanya would like to discuss in details the following questions:
        a. Information required by LCG VO to match the entry in ORGDB
           (DOB/badge number) etc
        b. Institutional, experimental and vo membership and expiration 
           dates in ORGDB
        c. Real necessity to implement the  match & choose mechanism 
           (how many people in ORGDB have multiple entries with the 
           same email, DOB or badge)
        d. Utilization of certificate  serial number for identification 
                Karoly 

3. Review of the previous meeting's minutes and actions 
   http://cern.ch/dimou/lcg/registrar/TF/meetings
                All 

4. Savannah tickets' review. What is open, what is 'Major', what is 
   wrongly assigned (e.g. see discussion on task 1185)
                All

5. AOB

1. Mandate briefing:

Vincenzo Ciaschini and Valerio Venturi start participating in the TF now so, its coordinator, Ian Neilson explained the mandate and current status recently presented at the EGEE Conference in Den Haag.

It is important to note that the technical solutions are being worked out now but official management commitment on resource allocation for development is still pending (see (*** ACTION 2004-09-17--13 ***) below. Luckily CNAF/INFN management committed in Den Haag on November 25th 2004 the continuation of voms-core code development and maintenance by Vincenzo with help from Valerio.

2. Open questions from ORGDB link:

2.a. Discussing DateOfBirth (DoB), CERN badge number and email address as candidates for unambiguous matching with the user's record in ORGDB we decided that the DoB or CERN badge number will be required for entry by the user but the actual matching will be done based on the email address.

2.b. Discussing all kinds of expiration dates we decided that we should join the Participation_End_Dates one may have as a user or as an experiment member and make a cut-off. This means that if (s)he expired as a user but the experiment record holds no expiration date, our software will remove him/her from the VO (with appropriate warning) and (s)he will have to action the relevant Team Leader (TL) for date information update in the ORGDB. If the database record gets updated during the 2-weeks warning period, the 'remove-from-VO counter' will stop. Reading the Questionnaire answers listed in the index of the TF working documents we can see how the experiment secretariats and the User Office interact with the users themselves and their TL.

2.c. Covered by the decision in 2.a. Email is unique but exception handling will be built-in, if needed.

2.d. The user cert. serial number will be logged but not stored.

3. Actions' status:

Only the following actions are completed:
- "document the recommended number and use of VOMS Groups and Roles" now covered in the relevant section of the document "Deploying a VOMS service".
- Karoly fixed several bugs in voms-admin. Version 0.7.4 is now available and the rpms were sent by email to Tanya and John.
The remaining pending actions are re-listed below from the minutes of the previous meetings. They are now numbered with unique reference numbers containing the date they were opened:

(*** ACTION 2004-09-17--1***) On Ian's suggestion Maria will create 3 savannah tickets containing all the existing VOMS/VOMRS-related tickets across groups per category (Major, Normal, Enhancements). PENDING

Ticket 860: Maria closed this ticket with Karoly's anwer. She opened ticket 1185 to describe the task of defining what to store on user's CA information. Please read the tickets for details. (*** ACTION 2004-09-17--2***) Tanya: VOMRS should also store the user certificate serial number and his/her CA's contact URL. CLOSE based on 2.d. above or modify to "log" as a Task reminder?

Ticket 1132: (*** ACTION 2004-09-17--3 ***) Tanya will make the necessary changes so that newly registered VOMRS users don't receive 2 almost identical emails when they pass from status "New" to "Approved" in the VO. By this date, Maria completed her action on making sure VOMRS notification emails will never fall into spam again. She informed the TF by email on the reasons and the solution (whitelisted the string "VOMRS" at the CERN central email gateway level). PENDING

(*** ACTION 2004-09-17--4 ***) Tanya should re-open the savannah ticket 1141 if a more user friendly error message can be envisaged by the VOMRS developers in case of expired user certificate. PENDING

(*** ACTION 2004-09-17--5 ***) Maria should make a CERN afs account for Tanya and do the necessary for her to obtain CVS write access. PENDING

(*** ACTION 2004-09-17--6***) Tanya will enter in the savannah group lcgoperation the bugs she has observed. Example: Simultaneous "commit" of changes via the User Interface and the VOMS db API causes the db tables to go out of sync. This is, most probably not a database problem but an application problem of voms-admin. PENDING

(*** ACTION 2004-09-17--7 ***) Recommend to CERN IT Management on information quality improvement for CERN HR db. (*** ACTION ***) Maria. PENDING (it can only be done when the ORGDB content quality is fully understood).

(*** ACTION 2004-09-17--8 ***) The ORGDB view with the necessary and sufficient Personal User data, according to the Requirements' definitions may need to be tailored according to experiments' rules Karoly and Maria to investigate and inform the TF. PENDING

(*** ACTION 2004-09-17--9 ***)Maria will test VOMRS and make available to the TF a list of features. By the time these notes are written, Tanya announced mid-December 2004 the pre-alpha version https://hotdog62.fnal.gov:8443/vo-LCG/vomrs for testing. PENDING

(*** ACTION 2004-09-17--10 ***) Tanya expressed worries that US-CMS users won't accept to type their birthdate, even if it is only DDMM (no year) and even if it is not logged in clear, simply a string saying that it was provided. She also said they might be reluctant to register in CERN HR db, even if this is LHC experiment policy. She should give the TF feedback from discussions on this matter with her community. PENDING

(*** ACTION 2004-09-17--11 ***) Maria create savannah ticket for VOMS admin and VOMRS to set Return-email-address to the one of the VO manager for user notifications that can't reach the recipients. PENDING

(*** ACTION 2004-09-17--12 ***) TF to re-discuss the Usage Rules re-acceptance prompt in more detail. PENDING

(*** ACTION 2004-09-17--13 ***) LCG deployment management has to plan for VOMS admin software maintenance continuity after Karoly's departure from CERN in April 2005. LCG/EGEE management has to plan for EDG trust manager support continuity after Joni Hahkala's departure from CERN. PENDING

(*** ACTION 2004-09-17--14 ***) Ian should investigate with the LCG Deployment management whether resources could be found elsewhere in the community to assist Tanya in the VOMRS development work. CLOSE after John's assignment to VOMRS development?

(*** ACTION 2004-10-28--1***) Tanya to make a UML diagram in addition to the VOMRS Registration Process flow and to the VOMRS_new_req document they prepared with John.

(*** ACTION 2004-11-29--1***) Karoly to make available a sceleton of Classes for VOMRS developers to use when interfacing to the ORGDB.

(*** ACTION 2004-11-29--2***) John and Tanya to submit in savannah (project=lcgoperation) the problems they mentioned at the meeting related to voms-core code when using "voms-proxy-init" and anything else they want to report to the developers. Savannah is the communication medium that helps the TF check where we stand in the process. All, please close tickets when actions done.

4. Savannah tickets' review:

This agenda item was covered via the actions' review.

5. A.O.B.

a. The Grid Deployment team needs to pass the operation of the VOMS service (in terms of server availability and data integrity) to the CERN IT DataBase (DB) group. The server currently runs reliably for more than a year on a Linux box (open with personal certificate https://lcg-voms.cern.ch:8443/edg-voms-admin/dteam/index.html) but we are seeking a more professional solution based on the Functional Requirements linked here. The DB group requires the VOMS service to be Oracle-based and not MySQL as it is today. Savannah ticket 1375 is opened to follow this requirement. The meeting participants expressed worries about Oracle licencing issues. By the time these notes are written Maria checked with the CERN Oracle liaison J. Shiers and got the confirmation that we have a licence that covers all CERN users in and outside CERN.

b. In order for the VOMRS developers to deliver at the end of February 2005 what was planned at the end of the 15-17 September 2004 workshop the ORGDB API must be ready a.s.a.p. As a reminder of the plan the extract of the relevant minutes is re-appended here:

-------------------------- begin
The changes required in VOMRS to cope with the LCG Requirements (Tanya's notes incorporated) are:

To be delivered in February (items ##4,7,8,9,10 must be done anyway in order to comply to the relevant requirement).:
1. Implement a registration procedure that will be using the ORGDB link to find the appropriate match for the candidate member. The user's ORGDB record should carry the specific experiment that corresponds to the VO he/she is applying. If he/she is found "Expired" because he/she moved to work for another experiment, a friendly notification should inform him/her that they should probably register with that other VO.
2. Implement an additional web interface and Web services that allow the VO manager to select the most suitable match in case of multiple entries in ORGDB.
3. Implement a Validation procedure that will be using the ORGDB interface to regularly check every VO member's data and affiliation to the VO.
4. Implement e-mail verification before going through the matchMember with ORGDB.
5. Modify the Registration form so the appearence of the Institute and Institute Representative fields could be configurable (they will be taken from ORGDB for the LCG VOMRS).
6. Mark clearly on the form which fields should be filled by the user.
7. Make the approval by the VO manager mandatory for adding a member to a VO. Today's VOMRS completes VODB registration after IR's approval.
8. Allow the VO manager to approve or deny any additional DN/CA added by the user.
9. Implement the VODB_Expiry_Date, issue an email notification to the member on that and add "Expired" status to the list of available statuses.
10. Add a "reason" field to any status, it should be filled by the VO manager for every status modification.
To be delivered after February:
1. Associate "Group Role" and "Role" with each DN & CA and not just with members.
2. Allow a member to select his/her Group and Role and the VO manager (Group Owner/Manager) to approve or deny the selection.
3. Sign all e-mails form VOMRS with the certificate where the VODB runs, e.g. alice-vo-registrar.cern.ch.

------------------------------ end

Next checkpoint meeting:

The VOMS deployment plan suggests these meetings take place monthly. The next meeting will be held on 18 January 2005 at 16hrs in room 28-R-006.

Maria Dimou, IT/GD, Grid Infrastructure Services