Difference between revisions of "Wider VO issues"
From GridPP Wiki
| Line 42: | Line 42: | ||
Comments to Chris at HEPSYSMAN: | Comments to Chris at HEPSYSMAN: | ||
| − | + | * reliability | |
| − | + | * easy of use | |
| − | + | * future proofing - LHC VOs dictate directions (e.g. move to CREAM, away from LFC) | |
| − | + | * WLCG stack is not complete (holes for data management etc.) | |
| − | + | * Hidden features | |
| + | |||
.... https://wiki.egi.eu/wiki/VO_Services/Services_and_Tools_Portfolio (found via Diane Ganga) | .... https://wiki.egi.eu/wiki/VO_Services/Services_and_Tools_Portfolio (found via Diane Ganga) | ||
| − | + | ** try not to lose portal and console developments in NGS (worked better with gram on CEs) | |
| − | + | ** free to support SARONGS in the UK | |
| − | + | * Had ngs for a long time but little real work submitted. Should NGS sites have UI point at GridPP WMSes? | |
| − | + | * Config changes break things inc. certificates. VO specific tests. What is Nagios support like for multi-VOs? | |
| − | + | * Manage VO expectations | |
| − | + | * Site admins need to be proactive -> raising VO issues to say TB-SUPPORT or proxy GGUS tickets | |
| − | + | * What about other solutions like boinc? | |
| − | + | * Typical use cases - should VOs define this when joining? | |
| − | + | * Repository of images for middleware. UI. Use of CVMFS. | |
| − | + | ** Observation of people taking up instructions (feedback). Config UI is complicated. Open UI? | |
UI with GSI ssh route - but then who to support? | UI with GSI ssh route - but then who to support? | ||
| + | = Done = | ||
| + | * Resilient VOMS servers | ||
Revision as of 10:54, 2 October 2014
This is part of the core operations team activites
The task involves:
1. Tracking new VO requests across the Grid and specifically those affecting UK resource providers.
2. Maintaining the extracts and details at: http://www.gridpp.ac.uk/wiki/GridPP_approved_VOs.
3. Tracking the status and problems experienced by the VOs and raising issues to the weekly ops-team meeting - Site enablement problems - User issues
4. Providing (or coordinating) help and support to new VOs who require guidance on becoming grid enabled.
TODO list
* Good practice
* For individual users of regional VOs
* for medium sized VOs
* An example data model
- Use checksums
- Custodial copies of data
- Keep multiple copies for load sharing and resilience
- Sending jobs to data
- Catalogue synchronisation (Use LFC)
- Sensible paths on storage
* VOMS - Resilience - Use of roles - Use of SaroNGS (aow obsolete)
* How to do stuff - Submitting jobs to data
* Job submission
* Ganga - Stuff for small VOs. * Dirac
Comments to Chris at HEPSYSMAN:
- reliability
- easy of use
- future proofing - LHC VOs dictate directions (e.g. move to CREAM, away from LFC)
- WLCG stack is not complete (holes for data management etc.)
- Hidden features
.... https://wiki.egi.eu/wiki/VO_Services/Services_and_Tools_Portfolio (found via Diane Ganga)
- try not to lose portal and console developments in NGS (worked better with gram on CEs)
- free to support SARONGS in the UK
- Had ngs for a long time but little real work submitted. Should NGS sites have UI point at GridPP WMSes?
- Config changes break things inc. certificates. VO specific tests. What is Nagios support like for multi-VOs?
- Manage VO expectations
- Site admins need to be proactive -> raising VO issues to say TB-SUPPORT or proxy GGUS tickets
- What about other solutions like boinc?
- Typical use cases - should VOs define this when joining?
- Repository of images for middleware. UI. Use of CVMFS.
- Observation of people taking up instructions (feedback). Config UI is complicated. Open UI?
UI with GSI ssh route - but then who to support?
Done
* Resilient VOMS servers
This page is a Key Document, and is the responsibility of Christopher Walker. It was last reviewed on 2013-12-16 when it was considered to be 5% complete. It was last judged to be accurate on (never).
