Planning Process for SC4

First version 25jan06 by Ian Bird, Erwin Laure and Les Robertson after discussions in the LCG MB on 10, 17 and 24 January.
This version 31jan06 by Les Robertson, reflecting comments received from the MB members - modifications in blue.

The TCG

The main purpose of the TCG is to agree on the priorities for the development teams within EGEE, taking account of the requirements and priorities of the different application communities, and the resources available to the developers. There are also various other constraints that need to be taken into account, such as the resources available for testing and deployment, the priority that developers have to give to maintenance of functionality already in production, and externally imposed timetables like the timing of the service phasing of LCG. In general the TCG will be looking at the medium term - planning for developments that could be made available in a distribution 6-9 months ahead (therefore released to deployment for testing 4-6 months ahead).

The current LHC machine schedule has led to the LCG MB deciding that SC4 must start at the latest on 1 June 06. This in turn leads to the following constraints on the delivery of the middleware:.

This schedule implies that very little other than the software already delivered to deployment will make it into the release for SC4 - in other words there is very limited scope for TCG decisions that will influence what is available in SC4.

In LCG we agreed that the deployment plan for SC4 will be fixed in advance on the basis of realistic assessments of software availability and of the time and resources required to fully test and deploy the components. This approach gives priority to availability and reliability over new functionality, but avoids the expectation gap that developed during 2005. This approach was strongly recommended by the experiment spokesmen in the OB and was presented in the meeting with the spokesmen on 13 January.

Jamie's service management team is responsible for preparing the plan for SC4. Flavia is drafting the plan, taking account of what can be delivered and supported by the developers (EGEE and others), integrated and tested by deployment, thoroughly tested by the experiments, and deployed by the sites - all within the time constraints of SC4. Realistically, as far as EGEE middleware is concerned, this plan can only include functionality already in the LCG2.7 distribution or in the gLite 1.5 code already in the hands of the deployment people. If we are to keep to the dates defined above there is no scope for adding additional functions, rather we must understand whether all of this functionality can realistically be deployed.

If we are to achieve an SC4 start date of 1 June we have to work to a very tight timetable. The target for the planning phase is to arrive at an agreement on the plan by the end of the Mumbai Service Challenge Workshop, to be documented during the following week and submitted for approval by the GDB (email). It should then be possible to agree the plan formally in the MB before the end of February.

Much of the new functionality discussed in the Baseline Services Working Group at the end of last year will not be ready for SC4. We must therefore begin to plan for another functionality release of the distribution in October 2006 (corresponding to the opening of the initial LHC service - assuming the the service must be fully commissioned by 1 April 2007). This places a constraint on the TCG middleware development planning, to deliver to deployment by the end of June.

The SRM 2.1 implementations are being delivered for testing during the first quarter of 2006. The SRM working group (run by Maarten Litmaath) must develop a testing and deployment plan that will run in parallel to SC4. This has to test compatibility between the implementation, support by the common clients (e.g. FTS, GFAL, lcg-utils), and testing by the experiments. The dates for introduction of SRM 2.1 will not be able to be decided until we are some way into the test programme.

New and novel functionality, such as GPBOX, may have to go through an evaluation process between developers and users before its final form is agreed. Such evaluations should be planned by the TCG in collaboration with one or more of the experiments. LCG would not be involved in a planning role so far in advance of availability.