TCB 20 May Requirements
Jump to navigation
Jump to search
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 |
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 |