Difference between revisions of "FrenchSitesInputtoTEGOp"

Un article de lcgwiki.
Jump to: navigation, search
(Input for WG4 - WG 5)
(What takes the most effort?)
 
(16 intermediate revisions by the same user not shown)
Ligne 1: Ligne 1:
 +
[http://lcg.in2p3.fr/wiki/index.php/TEG BACK to TEG]
 +
 
== Input provided by french sites ==
 
== Input provided by french sites ==
 
+
===  Input for WG4 - WG 5 Mware operational requirements, distribution, deployment, distribution ===
 
 
===  Input for WG4 - WG 5   ===
 
====Scope====
 
* '''Middleware operational requirements'''
 
** Example topics: log files, error messages, manageability, robustness, system requirements, documentation
 
* '''Service and middleware configuration'''
 
** Example topics: puppet, quattor, yaim...
 
* '''Service and middleware deployment'''
 
** Example topics: Packaging, upgrade paths, release schedules, rollout policy
 
* '''Middleware distribution'''
 
**Example topics: Distros - EMI, EPEL, UMD, OSG, repositories, OS support, source availability
 
  
 
==== What is in use currently and works well?====
 
==== What is in use currently and works well?====
* Quattor (FC)
+
* Mware integration using Quattor (long-term support essential)
  
 
==== Top problems====
 
==== Top problems====
* Too many information on logfiles or finding the good information on log file is too hard (IN2P3-LAPP)
+
* Mware usability : Too many information on logfiles. Finding the good information is too hard.
 +
Log management in order to improve Incident Detection and Traceability
  
 
==== What takes the most effort?====
 
==== What takes the most effort?====
* Middelware dependency understanding (IN2P3-LAPP)
+
* understanding the Middelware dependencies
 +
* reverse engineering of yaim scripts to understand what has changed in Mware configuration !
  
 
==== What can be improved about operational procedures?====
 
==== What can be improved about operational procedures?====
* A clear and single channel to announce a new release and documentation (IN2P3-LAPP)
+
* A clear and single channel to announce a new release and documentation
 +
 
 +
==== What can be dropped? ====
  
==== What can be dropped?====
 
  
 
==== Strategic directions you would like to recommend====
 
==== Strategic directions you would like to recommend====
* Middelware compatibilities with the larger set of technical constraints (yaim/quattor, NAS/SAN storage infrastructure,...) (IN2P3-LAPP)
+
* Improving Middelware compatibility with the larger set of technical constraints (yaim/quattor, NAS/SAN storage infrastructure,...), minimizing dependencies and extending the compliance with existing standard
  
 
==== Other comments====
 
==== Other comments====
* Aware of EGI stage rollout procedure ? (FC)
+
* Confidence in Mware : EGI staged-rollout on best effort basis. Is this sustainable ?  
* A clear statement regarding "EGI staged rollout procedures" is required from WLCG.  (FC)
+
* Still needed : relocatable version of Mware
 +
* Dropped too early : 32 bits UI
 +
* SL6 WN and disk servers may be needed soon (new hardware procurements)
 +
* Mware distribution via EMI and UMD : no enhancement of interfaces ergonomics (compared to what was available with gLite)

Latest revision as of 17:02, 16 novembre 2011

BACK to TEG

Input provided by french sites

Input for WG4 - WG 5 Mware operational requirements, distribution, deployment, distribution

What is in use currently and works well?

  • Mware integration using Quattor (long-term support essential)

Top problems

  • Mware usability : Too many information on logfiles. Finding the good information is too hard.

Log management in order to improve Incident Detection and Traceability

What takes the most effort?

  • understanding the Middelware dependencies
  • reverse engineering of yaim scripts to understand what has changed in Mware configuration !

What can be improved about operational procedures?

  • A clear and single channel to announce a new release and documentation

What can be dropped?

Strategic directions you would like to recommend

  • Improving Middelware compatibility with the larger set of technical constraints (yaim/quattor, NAS/SAN storage infrastructure,...), minimizing dependencies and extending the compliance with existing standard

Other comments

  • Confidence in Mware : EGI staged-rollout on best effort basis. Is this sustainable ?
  • Still needed : relocatable version of Mware
  • Dropped too early : 32 bits UI
  • SL6 WN and disk servers may be needed soon (new hardware procurements)
  • Mware distribution via EMI and UMD : no enhancement of interfaces ergonomics (compared to what was available with gLite)