Notes by Maria
Last update 2008-10-30 with Andrea's comments
Attendance
----------
Andrea, Dimitar, Maria, Steve, Tanya, Vincenzo
Also on 22 October: Patricia M.(UNOSAT, GEAR, GEANT4), Alessandro de
S.(ATLAS, by tel.), Joel C. and Roberto S.(LHCb), Martti P. (CMS).
and on 24 October am: Miguel A. (for the Oracle discussion).
Results of the vomrs functionality questionnaire to the VO Admins
Answers to the questionnaire by the VO Admins showed that there is not a single
VOMRS
feature we could ignore. Most features are used by all, those few not needed by some, are indispensable for others (e.g. point 6 on "Interfacing
third-party directory during registration and membership validation", is the only way to authenticate for LHC VOs and requested by D-Grids).
VOMRS/Voms-Admin convergence plan
Going through the list of
voms-admin development items (21 in total today) one by one, we saw the difficulty to pronounce any concrete deadline for the convergence. The
required functionality involves a lot of voms-admin development effort. The
EGEE-JRA1-Work-Plan-Tracking Task #7729 and dependent tasks 7719, 7720, 7721, 7722,
7723, 7725 contain very high-level descriptions compared to the expected functionality of the new voms-admin.
A slightly more detailed list is this:
- Items required by the up-to-date Joint Security Policy Group
JSPG Membership Management Policy document (or are very simple to implement)
are of 1st priority and will be in voms-admin-server-2.5. Original date was August 2008 but now this work can be expected sometime between January and
March 2009:
- Items on functionality required by VO Admins using VOMRS today will be done next (delivery date was not committed):
- Major development items remain the interface to an external information source. According to Andrea, this may come as late as the end of EGEE III
(Spring 2010). LHC experiment VOs cannot live without this feature, which they use since 2005, following a GDB requirement:
VOMRS future
- VOMRS certification will be done by Steve.
- A new VOMRS version is going into production before the end of October 2008.
- Tanya continues testing the new (Oracle?) bug with error message "Exhausted result set".
As it only hits LHC experiment VOs the last thing to stress-test is intense VOMRS activity with CERN HR db disconnected.
This will also be complete before the end of October 2008.
- Maria worried that if the convergence plan is very much delayed, backwards compatibility of the new and very different voms-admin to ensure VOMRS
synchronisation will not be easy. Andrea confirmed that no problems are foreseen on that side. The current interfaces that are exposed by VOMS-Admin
will continue to work as today, thus making VOMRS-VOMS synchronization possible as it is today.
A.O.B.
- Maria was 'actioned' to ask JSPG to include in the VO management policy document the requirement for the
administrator to be a VO member, hence to have signed, at least, the AUP.
Andrea explained that we should distinguish between people who can submit jobs vs. people that decide whether
someone can be part of a VO or not.
The issue that was raised at the meeting is that there is no clear VO Admin registration procedure in use
currently. VOMRS forces members that are registered in its database to sign the VO AUP. Nevertheless, a service manager can easily add
other administrators to the VO using voms-admin command line tools and of course these administrators should not be bound to be VO members
(i.e. people that can obtain a valid VOMS Attribute Certificates from a VO).
These trusted administrators are visible to VO Admins via VOMS-Admin command line and web interfaces.
- Steve asked Andrea to implement a flag to disable voms configuration creation from voms-admin-configure to separate voms-admin and voms-core
configuration in
order to migrate such configuration to the yaim module. Having them separate is useful when configuring VOMS replicas, for instance. However, the
functionality needs also to remain where it is (i.e., in voms-admin-configure) since it's used by clients that are not installing VOMS using the gLite
configuration tooling (OSG/VDT, for example).
- The special (bottom-up) DTEAM VO workflow, where the GroupOwner/GroupManager approves the candidate in
the group before the VO Admin has enabled him/her in the actual VO. A flag will be implemented to show the chain of approval authorities and the
necessary series of email notifications will be triggered per step when step-1 is completed.
When the new registration service is implemented, the necessary savannah bugs will be opened so that this behaviour may be tested.
- LHCb asks for quite sometime some functionality in the products vomrs/voms-admin allowing to change the VO member certificates in one go by the VO
Admin when a CA revokation occurs.
This is related to the very famous VOMS DN/CA pair issue that has been discussed for ages and will be hopefully fixed in the near future
allowing users to be verified only taking into account the DN.
- LHCb asks for an operational VOMS replica. On-going testing with
CNAF is reaching the end. VO Admins (for VO-ID cards' updates) and the yaim team will be informed by Steve when we are ready to enter production.