Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "TCB 20 May Requirements"

From EGIWiki
Jump to navigation Jump to search
(Created page with '{{Template:Op menubar}} = Summary of requirements collected by EGI = {{TOC_right}} List of requirements by EGI from the end of 2010 to February 2011. Every ticket is briefly…')
 
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Template:Op menubar}}  
{{Template:Op menubar}}  
= Summary of requirements collected by EGI  =
{{TOC_right}}
{{TOC_right}}
List of requirements by EGI from the end of 2010 to February 2011.
[[Category:Technology Coordination Board (TCB)]]
 
= RT tickets to be discussed at TCB May 20 =
Every ticket is briefly described, with a summary of the feedback from the technology providers if any. For a more exhaustive description of the request, and to read the discussion that followed the ticket submission, follow the ticket link.
 
'''Note:''' This is a static page, last update: ''19-May-2011 18:30''
 
<br>
 
=== Installability  ===
 
{{Template:Requirement_description
| O_tn=1357
| O_title=Middleware use standard file locations
|O_desc=Currently services create a huge amount of temporary files and logs, not all of them are in standard locations. Services should create all the logs files under /var/logs, and the temporary files under /tmp.
Having all the files under the same path makes easier to parse and collect the logs.
|O_tp_comment = EMI: Most of the EMI services already comply with the requirement, nevertheless covered by EMI objective, will be included in the EMI-2 plans.
|O_egi_comment =}}
 
 
{{Template:Requirement_description
| O_tn=1379
| O_title=Better configuration of services using mysql backend.
| O_desc=Many services need a custom configuration of the database backend to improve their performance. This configuration should be provided with the service, and automatically applied where possible.
|O_tp_comment = The requirement will be part of EMI-2 workplan.
|O_egi_comment =}}
 


===Previous requirements still under discussion===
{{Template:Requirement_description  
{{Template:Requirement_description  
| O_tn=1022
| O_tn=1022
Line 39: Line 14:


{{Template:Requirement_description  
{{Template:Requirement_description  
| O_tn=1186
| O_tn=1378
| O_title=New features for target system
| O_title=Publishing middleware service versions
| O_desc=New features for Target System: Support for clusters without a shared FS, Possibility to define resources offered by a site per queue in IDB (assuming full support for queue selection, Possibility to freely split IDB into multiple files. Except of better manageability this would allow us to easy and automatically update some of SSR supported by a site.
| O_desc=All the services should publish in the information system the service version, and the middleware release. Other additional request, automatically gathered from the operating system, should also be published: o.s., architecture..
|O_tp_comment = EMI required more information.
|O_tp_comment = EMI endorsed the request, more information about what and how will be published are needed.
|O_egi_comment =}}
|O_egi_comment = A proposal about how to map these information on GLUE2 has been forwarded to EMI}}  




{{Template:Requirement_description  
{{Template:Requirement_description  
| O_tn=1388
| O_tn=881
| O_title=Better documentation on service replication and load balancing configurations
| O_title=Requirement for VO renaming / migration
| O_desc=Middleware providers should provide documentation on how to easily migrate stateful services from a machine to another (e.g. how to migrate databases and data files). Documentation on high availability configuration is also needed.
| O_desc=The first part of the requirements is to implement a mechanism to allow users to migrate their data between the VOs they are member of. This would also easy the VO renaming process. <br> The second part of the requirement is to extend the authorization and authentication mechanism to the VO aliases (defined by OPS portal).
|O_tp_comment = EMI will not take a general requirement on documentation. Where available HA configurations descriptions should be already provided being part of the documentation policy of EMI.
|O_tp_comment = EMI security team reported that the requirement is not well specified, and not clear.
|O_egi_comment =}}
|O_egi_comment =Requester reported a use case: Users (and VO administrators) are interested in migrating data from one VO1 to another VO2 in a transparent way. This should be done without doubling the space needed for the data, and without downloading/uploading the files.}}  
 
 
{{Template:Requirement_description
| O_tn=1381
| O_title=Improve YAIM configuration
| O_desc=YAIM functions should automatically get as many parameters as possible. E.g. operating system and architecture, needed in the cluster configuration, should be configured automatically.
|O_tp_comment = YAIM is not fully supported by EMI
|O_egi_comment =}}
 
 
===Portability===
 
{{Template:Requirement_description
| O_tn=1202
| O_title=Uniform logging format
| O_desc=Middleware services should uniform their logging format.
|O_tp_comment = EMI won't endorse this requirement. Changing the log format would break a number of monitoring tools that parse the logs. In case of specific problems open a GGUS ticket.
|O_egi_comment =At least there should be some common rules to avoid common problems in parsing the logs.}}
 
 
{{Template:Requirement_description
| O_tn=1201
| O_title=Homogeneity in service control
| O_desc=Requirement to have a standard, uniform, way to start/stop services.
|O_tp_comment = EMI endorsed this requirement as part of EMI-2 technical plan.
|O_egi_comment =}}
 
 
===Usability===
{{Template:Requirement_description
| O_tn=1380
| O_title=Better WMS configuration tools, and monitoring.
| O_desc=Many configuration/setup tricks are in the manual pages of WMS, but not yet implemented in the automatic configuration of the services. From the max number of connections to automatically clean the ICE persist directory.
|O_tp_comment = Open a GGUS ticket to the product team.
|O_egi_comment =}}
 
 
{{Template:Requirement_description
| O_tn=1184
| O_title=Brokering and Matchmaking support for new site info system types
| O_desc=UNICORE: Use of SSr in brokering process, and extensions to service orchestrator.
|O_tp_comment = EMI does not support those components.
|O_egi_comment =}}
 




Line 104: Line 35:
|O_tp_comment = EMI requested clarifications, before the endorsement
|O_tp_comment = EMI requested clarifications, before the endorsement
|O_egi_comment =The simplest and probably the most useful scenario is the following: among the available VOs there is the possibility to choose which ones have the "mandatory flag" enabled}}
|O_egi_comment =The simplest and probably the most useful scenario is the following: among the available VOs there is the possibility to choose which ones have the "mandatory flag" enabled}}
{{Template:Requirement_description
| O_tn=1382
| O_title=Documentation on different implementation of the same service
| O_desc= The technology providers should provide comparison tables for the different implementation of the same service.
|O_tp_comment = EMI endorsed the requirement.
|O_egi_comment =}}
{{Template:Requirement_description
| O_tn=1230
| O_title=Uniform API
| O_desc=Request to have a uniform set of APIs to control all the services.
|O_tp_comment =
|O_egi_comment =}}
===Operability===
{{Template:Requirement_description
| O_tn=1674
| O_title=Unify SRMv2.2 port
| O_desc=Different implementation of the SRM service are answering on different ports (dCache implementation and DPM). In general the same service should provide the same default port in all its implementations.
|O_tp_comment =
|O_egi_comment =}}
===Job Management===




Line 142: Line 44:
|O_egi_comment = A survey on the batch systems deployed/wanted has been launched by EGI in May-June 2011 }}
|O_egi_comment = A survey on the batch systems deployed/wanted has been launched by EGI in May-June 2011 }}


{{Template:Requirement_description
| O_tn=1283
| O_title=MPI-start improvement
| O_desc=Currently MPI-start does not support hybrid MPI-openMPI application and cpu/memory affinity between worker nodes involved in the process.
|O_tp_comment = EMI requested to forward the request to the specific product team.
|O_egi_comment =}}
{{Template:Requirement_description
| O_tn=1385
| O_title=Interactive job monitoring
| O_desc=Request for more tools to monitor runnign interactive jobs.
|O_tp_comment = EMI requested more details, and a more specific requirement.
|O_egi_comment =}}




{{Template:Requirement_description  
{{Template:Requirement_description  
| O_tn=1386
| O_tn=1388
| O_title=Storm file protocol
| O_title=Better documentation on service replication and load balancing configurations
| O_desc=Storm should support the direct access file protocol
| O_desc=Middleware providers should provide documentation on how to easily migrate stateful services from a machine to another (e.g. how to migrate databases and data files). Documentation on high availability configuration is also needed.
|O_tp_comment = Storm server already supports the ''file://'' protocol. The endorsed request is to enable it in the clients.
|O_tp_comment = EMI will not take a general requirement on documentation. Where available HA configurations descriptions should be already provided being part of the documentation policy of EMI.
|O_egi_comment =}}  
|O_egi_comment =The first part of the ticket requests service migration documentation for all stateful services. Migrating a service from a machine to another one, usually, is a procedure to solve some problems: asking to EMI the instruction when they are needed could be too late. From this point of view a general requirement on documentation could be reasonable.}}




===Usability===


{{Template:Requirement_description  
{{Template:Requirement_description  
| O_tn=1378
| O_tn=1202
| O_title=Publishing middleware service versions
| O_title=Uniform logging format
| O_desc=All the services should publish in the information system the service version, and the middleware release. Other additional request, automatically gathered from the operating system, should also be published: o.s., architecture..
| O_desc=Middleware services should uniform their logging format.
|O_tp_comment = EMI endorsed the request, more information about what and how will be published are needed.
|O_tp_comment = EMI won't endorse this requirement. Changing the log format would break a number of monitoring tools that parse the logs. In case of specific problems open a GGUS ticket.
|O_egi_comment = A proposal about how to map these information on GLUE2 has been forwarded to EMI}}  
|O_egi_comment =At least there should be some guidelines to avoid common problems in parsing the logs.}}




{{Template:Requirement_description
===New requirements===
| O_tn=1177
| O_title=Archaic DRMAA interface version enabled in glite-TORQUE_server breaks functionality
| O_desc=Old dependencies are breaking some functionalities of glite_TORQUE
|O_tp_comment = Submit bug report.
|O_egi_comment =}}
 


{{Template:Requirement_description  
{{Template:Requirement_description  
| O_tn=1183
| O_tn=1674
| O_title=UNICORE: Site info system enhancements
| O_title=Unify SRMv2.2 port
| O_desc= UNICORE info system should support String, Integer, Enum types for SSR. And information on the expected waiting time of the job in the queue.
| O_desc=Different implementation of the SRM service are answering on different ports (dCache implementation and DPM). In general the same service should provide the same default port in all its implementations.
|O_tp_comment = EMI endorsed the requirement, fill a GGUS ticket with the requirement.
|O_egi_comment =}}
 
 
 
{{Template:Requirement_description
| O_tn=1383
| O_title= cluster information
| O_desc=The information described by the glite-CLUSTER compoent should be implemented in CREAM and in other implementation of computing capacity.
|O_tp_comment = Requested more details
|O_egi_comment =}}
 
 
 
{{Template:Requirement_description
| O_tn=1188
| O_title=GUI enhancements
| O_desc=Requirement for enhancements in the UNICORE GUI
|O_tp_comment = EMI does not endorse the requirement, because the component is not in EMI
|O_egi_comment =}}
 
 
===Serviceability===
 
{{Template:Requirement_description
| O_tn=881
| O_title=Requirement for VO renaming / migration
| O_desc=The first part of the requirements is to implement a mechanism to allow users to migrate their data between the VOs they are member of. This would also easy the VO renaming process. <br> The second part of the requirement is to extend the authorization and authentication mechanism to the VO aliases (defined by OPS portal).
|O_tp_comment = EMI security team reported that the requirement is not well specified, and not clear.
|O_egi_comment =Requester reported a use case: Users (and VO administrators) are interested in migrating data from one VO1 to another VO2 in a transparent way. This should be done without doubling the space needed for the data, and without downloading/uploading the files.}}
 
 
{{Template:Requirement_description
| O_tn=1189
| O_title=Server-side management tools
| O_desc=UNICORE need management tools for: easy identification of orphaned job directories; possibility to convert old state DB to the newer server; current activity status of the server; ability to disable job submission. Easy way to trace a user's job for support purposes.
|O_tp_comment =
|O_egi_comment =}}
 
 
===Availability===
{{Template:Requirement_description
| O_tn=1181
| O_title=glite-BDII hangs, service status reports "bdii OK"
| O_desc=The service status for BDII does not report hanging statuses.
|O_tp_comment = Fill bug report.
|O_egi_comment =}}
 
 
{{Template:Requirement_description
| O_tn=1384
| O_title=DOS attacks
| O_desc=Services should be able to protect themselves against misuses. E.g. a dCache server can be easily killed by a huge amount of legal requests submitted simultaneously by the same user.
|O_tp_comment = EMI makes sure that each service comes with some sort of configurable resource protection. However, general protection against DOS is not possible.
|O_egi_comment =}}
 
 
{{Template:Requirement_description
| O_tn=1607
| O_title=accounting monitoring must be sufficient to decide whether all deployed middlewares of a site publish (correct) accounting data
| O_desc=If a site deploys more than one middleware, the monitoring of accounting should check if all the computing elelment of the different stacks are publishing their accounting data. The same problem could be raised about multiple CE in the same site.
|O_tp_comment =  
|O_tp_comment =  
|O_egi_comment =}}
|O_egi_comment =}}
===File Access===
{{Template:Requirement_description
| O_tn=1187
| O_title=Some new features for Data Mgmt and Sharing
| O_desc=UNICORE. Support for end users collaboration, manipulating permssions, logical SMS
|O_tp_comment = EMI does not support that UNICORE component.
|O_egi_comment =}}




Line 271: Line 78:
| O_desc=SRMv1 is not used anymore on DPM. It could be removed
| O_desc=SRMv1 is not used anymore on DPM. It could be removed
|O_tp_comment = Not submitted yet.
|O_tp_comment = Not submitted yet.
|O_egi_comment =}}
===Performance===
{{Template:Requirement_description
| O_tn=1173
| O_title=Increase of LB WS interface performance
| O_desc=LB performance decrease when the WS interface is used.
|O_tp_comment = EMI endorsed the requirement, but it is low priority
|O_egi_comment =}}
{{Template:Requirement_description
| O_tn=1182
| O_title=glite-CREAM consumes a lot of memory
| O_desc=After about a month of uptime CREAM-CE performance decrease because of the memory usage.
|O_tp_comment = EMI endorsed the requirement in the objective: "Increase performance of EMI services", that will be in the EMI-2 tech. plan.
|O_egi_comment =}}
|O_egi_comment =}}

Latest revision as of 16:43, 16 October 2012

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


RT tickets to be discussed at TCB May 20

Previous requirements still under discussion

RT ticket number 1022
Requirements title UI dependencies on python 2.4
Requirement description Middleware components should get rid of obsolete dependencies, that could be not available in more recent s.o.
Comment from Technology provider It seems that the main problem is Ubuntu, EMI will make available UI on ubuntu.
Answer(s) from EGI/requestor Requester asked to check if also other components have those obsolete deps.
Status status


RT ticket number 1378
Requirements title Publishing middleware service versions
Requirement description All the services should publish in the information system the service version, and the middleware release. Other additional request, automatically gathered from the operating system, should also be published: o.s., architecture..
Comment from Technology provider EMI endorsed the request, more information about what and how will be published are needed.
Answer(s) from EGI/requestor A proposal about how to map these information on GLUE2 has been forwarded to EMI
Status status


RT ticket number 881
Requirements title Requirement for VO renaming / migration
Requirement description The first part of the requirements is to implement a mechanism to allow users to migrate their data between the VOs they are member of. This would also easy the VO renaming process.
The second part of the requirement is to extend the authorization and authentication mechanism to the VO aliases (defined by OPS portal).
Comment from Technology provider EMI security team reported that the requirement is not well specified, and not clear.
Answer(s) from EGI/requestor Requester reported a use case: Users (and VO administrators) are interested in migrating data from one VO1 to another VO2 in a transparent way. This should be done without doubling the space needed for the data, and without downloading/uploading the files.
Status status


RT ticket number 1282
Requirements title Requirement for VOMS/VOMSAdmin and for the accounting systems
Requirement description Requirement for the possibility to force a user to choose a VO-group at the moment of VO registration. This is needed for catch-all VOs, where the VO groups identify the actual user research community.
Comment from Technology provider EMI requested clarifications, before the endorsement
Answer(s) from EGI/requestor The simplest and probably the most useful scenario is the following: among the available VOs there is the possibility to choose which ones have the "mandatory flag" enabled
Status status


RT ticket number 1235
Requirements title Batch systems supported by EMI
Requirement description The EMI computing elements should support a larger set of batch systems, the support (at least for the more important LRMS) should be guaranteed for the future. Another request was to have a common set of batch systems explicitly supported by all the Middleware stacks.
Comment from Technology provider (It is not a requirement directly addressed to EMI) EMI endorsed the requirement, but more clarifications are needed, starting from a list of needed batch systems needed/required by sites.
Answer(s) from EGI/requestor A survey on the batch systems deployed/wanted has been launched by EGI in May-June 2011
Status status



RT ticket number 1388
Requirements title Better documentation on service replication and load balancing configurations
Requirement description Middleware providers should provide documentation on how to easily migrate stateful services from a machine to another (e.g. how to migrate databases and data files). Documentation on high availability configuration is also needed.
Comment from Technology provider EMI will not take a general requirement on documentation. Where available HA configurations descriptions should be already provided being part of the documentation policy of EMI.
Answer(s) from EGI/requestor The first part of the ticket requests service migration documentation for all stateful services. Migrating a service from a machine to another one, usually, is a procedure to solve some problems: asking to EMI the instruction when they are needed could be too late. From this point of view a general requirement on documentation could be reasonable.
Status status



RT ticket number 1202
Requirements title Uniform logging format
Requirement description Middleware services should uniform their logging format.
Comment from Technology provider EMI won't endorse this requirement. Changing the log format would break a number of monitoring tools that parse the logs. In case of specific problems open a GGUS ticket.
Answer(s) from EGI/requestor At least there should be some guidelines to avoid common problems in parsing the logs.
Status status


New requirements

RT ticket number 1674
Requirements title Unify SRMv2.2 port
Requirement description Different implementation of the SRM service are answering on different ports (dCache implementation and DPM). In general the same service should provide the same default port in all its implementations.
Comment from Technology provider
Answer(s) from EGI/requestor
Status status


RT ticket number 1673
Requirements title SRMv1 to be removed from gLite DPM box
Requirement description SRMv1 is not used anymore on DPM. It could be removed
Comment from Technology provider Not submitted yet.
Answer(s) from EGI/requestor
Status status
Retrieved from "https://wiki.egi.eu/w/index.php?title=TCB_20_May_Requirements&oldid=42609"