Discussion on VAPOR features with France Grilles VO
Discussion with France Grilles VO about VAPOR features
1. Intro - FG to explain the model of the VO
VO fo.francegrilles.fr created mid-2011 to meet needs of new national users who do not fall in any existing community => catch-all national VO.
~35 active users, 20 site admins to test VO configutation on their sits. ~15 "real" users.
The users'needs can be either ponctual (to make an one-shot experiment), or in the longer term.
Once they are familiar with grid technologies, users may join other bigger VOs in their field or initiate the creation of a specific VO.
- Resource allocation:
The VO is supported by most french sites, with no guatanteed resource (opportunistic model).
- Support model:
So far, no formal support team. Support is provided by the labs/sites which users comes from.
This model is sufficient today since there are few users. But in the future, there is a need for a solution of collaborative support.
- Services:
The national instance of DIRAC maintained by FG is open to the FG VO.
LFC and VOMS are mutualised with other VOs (such as biomed), maintained by CC.
No Nagios dedicated to the VO.
2. List of features defined in VAPOR, get feed back from FG VO:
Info: VAPOR to be integrated into VO Operations Dashboard
FG deems this a good point given the common concerns of both tools.
VO users management:
Users database, User life cycle management, integ. with external services
FG: this is definitely interesting. Until now, the FG VO is below a critical mass of users that makes things easy to manage. But in the middle term, need for a users database to store additional admin information.
FG: To be included in the users db: free text field for VO admin to note user's research field, why the user was accepted into the VO, what are their scientific collaboration, etc.
Suggestion: at registration time, the user may pick up research fields from the discipline classification recently published by the VT Scientific Discipline Classification (https://wiki.egi.eu/wiki/VT_Scientific_Discipline_Classification)
FG: How to synchronise the VOMS and the user database?
When possible data should not be duplicated, but this is unavoidable for implementation concerns.
1. Data should be modifiable by VO admins only, users should keep on using the VOMS interface to register.
2. A synchro mecanism can be developed, based on the possilbilites offered by the VOMS APIs (GUI, CLI, any other?). In particular, we could use the moment users have to sign the AUP every year to make this synchronization.
Robot certificates:
The FG VO is not concerned by this need today.
Users mailing lists:
FG need: feature to export the email addresses of all users. If technically possible, a filter should allow to list only active users.
Track scientific publications:
VAPOR can contact Genevière who is in the VT about publications tracking.
VO Operations management for VO support teams
Resource status indicators, statistical reports
- Report GOCDB and BDII status
FG: How to avoid to submit a ticket for an alarm that is already taken care of in a ticket submitted by some other VO?
=> to be checked if this can be implemented in the VO Operations Dashboard as an improvement of the existing ticket submission assistant.
FG: this could also be interesting for LHC VOs. Renaud Vernet (resp. tier 1 Lyon, Atlas), already discusssed this with VO Operations Dashboard team, to be checked out with Cyril L'Orphelin. Also to be checked with Alexandra Forti (Manchester, Atlas).
- Advertise critical resources downtimes
FG: LHCb probably has some existing procedures on this subject. The Operations Portal does this kind of filtering, probably quite simple to do that in the Operations Portal itself, to filter only a subset of services. Possible notification by email or rss.
- Monitor resources availability
a) monitoring to detect when there are problems
FG: DIRAC already provides some reports, if not sufficient DIRAC team could consider the development of such statistical reports.
b) provide a list of CEs that "work fine" at a given moment (white-list)
FG: Not really useful in case users use DRIAC, since pilot jobs handle this problems: it a CE is not working, then no pilot job will run and consequently no user job will ever waste time waiting there.
For applications that need reactive resources, DIRAC is a good solution in itself.
Danger: maybe the timeout will prevent from running on some site, although the site would ultimately run the jobs anyway, even if this is after 10 hours. That may be a bad thing to "ban" a site in some cases.
VO Data Management: file migration and cleaning procedures
- Remove old files
Certainly useful for FG VO, either files letf behind or when a user leaves the VO.
- Deal with SEs filling up
FG: Very useful for VO managers, but also for site admins as it allows to anticipate the pbs. It is preferable to have a VO with proper tools that says "hey we may have a problem" rather than a VO that says "we have a problem now".
- Consistency between LFC and SEs: zombie & ghost files
Would be useful for FG VO.
SE decomissioning to add into the feautres, very close to the management of full SEs. Link with the decomisioning procedure of EGI.
Community Accounting
Not discussed, FG to provide feed back offline if needed.
