Minutes of the TCG meeting, 9 Nov 2005 -------------------------------------- Attending: Erwin Laure (Chair) Markus Schulz (Deputy Chair/SA3) David Smith (secretary) Jean-Paul Gaultier (SA2) Mathieu Goutelle (SA2) Claudio Grandi (JRA1) John White (JRA1-security) Cal Loomis (NA4) Massimo Lamanna (NA4), Federico Carminati (ALICE) Laura Perini (ATLAS) Dario Barberis (ATLAS) Andrei Tsaregorodstev (LHCB) Johan Montagnat (BIOMED) Stefano Belforte (CMS) Apologies: Ian Bird (SA1) Special Guest: Bob Jones (NA1) Chair: Regarding the Technical Coordination Group (TCG) Mandate Two sets of relevant documents, my presentation and the TCG mandate. High level goal of the TCG is to coordinate service activities, SA1, SA2, SA3, JRA1 with applications & experiments. Having a moderate number of members is hoped to help this process. Mode of working: The TCG should get input from stakeholders (esp applications), for example where they have showstoppers. In addition input from security and SA1+SA3 will be taken. TCG will collect, prioritize and hand over to SA3 who will collect the list of services which should eventually be in the release. SA3 comes up with a plan and gives out concrete requests after endorsement by the TCG. SA3 then has mandate to produce the release and SA1 deploys - with iteration on testing. TCG is chaired by Erwin Laure (myself) as technical directory. Issues arising from TCG can be brought to the project execution board (PEB). Any questions? [No] Deputy Char/SA3: Time scale for TCG activity should be relatively short (eg. different from the architecture forum). We want to make the previous scheme [in SA1] more transparent. LHCB: Next six months is also important. Deputy/SA3: Yes it's important and it's still probably what I'd call short term. Chair: We can form focused working groups. Members of the working groups need not be TCG members. The working group will be mandated to discuss a certain topic. eg. the baseline working group had a working group for SRM, which discussed the midterm plan for SRM. (eg. 6 or even 9 months timeframe). Similar things in the biomed area, eg. encrypted data store working group. Other example, how to deal with short jobs on the grid. I propose that these sorts of discussion are spawned off into working groups. [How does the baseline working group compare to TCG?] Chair: The baseline working group will still tie up some loose ends and produce a final updated document. eg, in my slides I've indicated certain inputs to our discussion. These can include documents from the baseline working group and the JRA1 workplan. We also have the existing architecture and design document. JRA1: Who is officially in change or architecture? Chair: JRA1, the architecture group is in JRA1. JRA1: Since JRA1 is responsible for architecture, maybe JRA1 has input to TCG. Chair: Indeed. JRA1 gives input but not requirements. Deputy/SA3: Architecture from JRA1 doesn't drive the way production services are put together - it's driven by the applications. That is why JRA1 isn't seen as a stakeholder, the architecture isn't seen as a requirement. JRA1: That means that the architecture has to be revised. Deputy/SA3: The TCG should provide the evolution of the software [driven] from the applications. JRA1 is there as an expert, but is not steering as only the JRA1 architecture dictates. Of course there is always some give and take. JRA1: If components don't behave as envisaged then the architecture might break. Chair: Of course - the input to the TCG would then be a warning about violations of the architecture. That is all I wanted to say about the proposed mode of working and working groups. Any further questions? NA4: Timescale? How often do you expect to go through this loop? How often will there be new releases? Chair: I don't think we should predefine cycles. But the loop should be on the short scale (of the order of a week for initial feedback on eg, missing components) Deputy/SA3: The time until the component is integrated depends largely on the quality of the component, the result of the applications looking at the component and the certification process. Chair: We should be flexible. Applications will find out as they use the system and will come back to the TCG with problems. Deputy/SA3: For example, taking one component: The VOBOX. The requirement came from the baseline services working group. A prototype was made based on discussion with the group the required it. At first glance it appeared to provide what they needed. When exposed to sites a lot of feedback came, particularly from security people. Then more feedback from applications with new requirements. With the service challenges we have to work on the short timescale. eg. sometimes we might have to meet relatively frequently. If we introduce a new service often more requirements come when the service starts to be used. [How long to come up with the functionality?] Chair: Depends on what is available. If a component exists then it can be fast otherwise maybe development is needed. Then perhaps the timescale is months. CMS: eg. on your [Chair's] slide 3, there is a diagram of information flow. Is the form of this flow documents or direct interaction during the TCG meeting? Chair: Yes it shows information flow. We hope this can happen during the TCG meeting. Deputy/SA3: However there should be a certain level of documentation. [If there are lots of documents we should take care to avoid the danger of becoming 'secretive'] Chair: Yes, we should be open. Deputy/SA3: At the moment [in SA1] we are largely running a wish list in public, via a list that is put on the wikki for public comment. However even if we remain open we should set the priorities within the TCG [and not have them dictated]. Alice: What about the timescales of experiments? What about freezes? Chair: Applications bring their timescales as a requirement. Deputy/SA3: Regarding 'freezes' - it depends on what is meant by freeze. eg. security patches should never be frozen out. We should also still allow for addition of other services for other VOs. Chair: Applications have milestones with dates and from those dates onwards they need to be able to work in a stable environment. But we need to continue to support other applications while we maintain stability. Alice: Depends on the meaning of release. If something comes too late (in a usable form for us) is might not get used Chair: This is an important input - eg. we need certain functionality by this time. Then, eg. JRA1, will say whether it is possible. In the TCG we should discuss all these issues. Applications should bring their requirements and timescales. Deputy/SA3: Also means we might release services that are not bundled up with a release. So we can update things as needed. eg. as is the case with the update of core services for the service challenges at present. Chair: Regarding openness: We will have an open web page which gives documentation. We will put all the minutes on the web page, which will be openly available. Maybe we should not minute 'screaming and shouting'? Deputy/SA3: In the baseline working group it was found to be good to have verbatim minutes. Otherwise you can go back after 3 months and find that you cann't understand the exact reasoning for some decision. I suggest verbatim minutes that are not public. Have the conclusions as minutes which are publicly available. Otherwise the minutes have the reasoning missing. Chair: Don't see why the verbatim minutes cannot be public. If we have strong disagreement we can still make it public. Deputy/SA3: Still need a summary so to avoid having to go through all the back and forth. Chair: Yes we need a summary and action list, so that we can see how we got on with action items. So that is it for the web site. We also have a mailing list. Should it be an open mailing list or just closed for submissions to the members of the TCG? The pro for keeping it closed is that otherwise it can degrade into general discussion of everything. Deputy/SA3: Indeed, open lists can take a huge amount of time. One can find a few people that send many mails which start many arguments. Chair: I agree - which is why I proposed to keep it closed. JRA1 (security): How about a public and private list, like in JRA3? [If the minutes are open then we can have a closed mailing list. And in any case should we restrict the posting?] Chair: Probably we should restrict the posting to members of the list, we should get less spam! Deputy/SA3: If TCG members get interesting comments they can forward them to the mailing list. CMS: I think it would be good if the mailing list is restricted. But what is sent should be considered public text Chair: We're a technical group - should try to keep personal and political issues out. JRA1: The archive could be public. Deputy/SA3: About the role of the technical director (as chair); We should agree that the decisions of the group are communicated through the Chair only. In the past, in other groups, there has been confusion - we should try to avoid that by having official statements sent through the Chair. [Is this saying that nobody should 'move' unless the Chair says so?] Deputy/SA3: Nothing is an agreed plan until the Chair communicates it to the outside world. Chair: I will check the conclusions and put it on the web page. This should mean they are agreed. However, if a member then says this is not correct we can of course come back and sort it out. But if we do stick to a well defined route of communication it should be better than if each member gives out their own interpretation. Chair: I move on to membership. We need to have chair, deputy and secretary. Then representatives for SA1 (as whole) and SA1 (for the sites) - representatives for SA2, SA3, JRA1 (middleware) and JRA1 (security), NA4 and taskforce leaders: task forces are ALICE, ATLAS, LHCB, CMS and BIOMED: each member should have an alternate who keeps track of what is going on in the group, in case the primary cann't attend. We have: Chair - Erwin Laure (NA1) - with Markus Schulz as alternate Deputy - Markus Schulz (SA3) Secretary - David Smith SA1 - Ian Bird/Alternate? ? (Site representative) SA2 - Jean-Paul Gaultier/Mathieu Goutelle SA3 - Markus Schulz/Alternate? JRA1 - Middleware - Claudio Grandi/Alternate Security - John White/Joni Hakahla NA4 - Cal Loomis/Massimo Lamanna Task Force leaders: Alice TF - Federico Carminati/Latchezar Betev ATLAS TF - Laura Perini/Dario Barberis CMS TF - Stefano Belforte/Alternate LHCb TF - Andrei Tsaregorodstev/Philippe Charpentier Biomed - Johan Montagnat/Alternate For the SA1 site representative we're looking for a person, preferably not one from a huge centre, but from a medium sized site. The site should also be multi disciplinary. CMS: CMS alternate still to be found, not sure it will be Ian Fisk who is on the initial list. Chair: With the members we have now I think we can start working. If anyone has problems with the membership they can send me a private communication. Next, we should start on a few things: There is an upcoming milestone for SA3 which could be a starting point. Get service inventory and gaps, which could be a starting point for our discussions. Other issue: There was an agreement in Pisa (EGEE conference) that there should be one single EGEE release. It is up to the TCG to define the contents of the common release. We don't want to miss something important. What should be the frequency of our meetings, how long and when? I believe that we will soon need weekly meetings. They should be short, say not longer than 1.5 hours. We need to stop discussion during the meeting if it gets too long. So I propose weekly meetings. For the time, is Wednesday a good time? Atlas: After 11am Chair: That would be a good time as we have to finish by lunch. Shall we say Wednesday 11am? NA4: [To Cal, NA4] Can we move our [NA4] regular meeting? Cal: Should be ok. Deputy/SA3: But if we need a US based expert it will be a bad time for them. Chair: But practically speaking afternoon are mostly taken already. Deputy/SA3: OK, 11 isn't bad. Chair: If it is impractical we can find another solution. First regular meeting next week. But I [Erwin Laure] will be in the US, so it will be lead by the deputy chair. Any other comments or questions? Bob: When we discussed the TCG in the PMB everyone was very keen to see the TCG work, so good luck Deputy/SA3: Maybe we should define what we need to discuss next time. LHCb: I have a general question. How do we imagine reaching decisions. eg. do we expect to have unanimous decisions? Do the actions have to be endorsed by 1 expert or 2 - or a majority of stakeholders?] Chair: My dream would be to have a consensus decision. Some things are specific to one application domain - but which might impact others. eg. if BIOMED needs to encrypt files on an SE but HEP doesn't. That doesn't impact HEP, unless the software providers were to say it is impossible to do both. In that case it would be a difficult decision. In that case not even a majority decision is good enough. We would need to minute it and bring it up at a higher level. Voting is the worst we can do. Deputy/SA3: Voting would only be acceptable if certain roles were to have a veto. Chair: We need to come up with a consensus, if providers say they cann't we'd need a compromise. But this is a small group and we will see how it goes. Many people have to leave now for the GDB. Let's close the meeting now. Deputy/SA3: Next time we should discuss the merging process between releases. Chair: I will send out an agenda for the next meeting. We'll send minutes to the mailing list this time, until the web pages are setup. END OF MEETING -- ------------------------------------------------------------------------- David Smith e-mail: David.Smith@cern.ch tel: +41 22 76 74462 Address: D. Smith, CERN G06610, Bat 28 R-007, 1211 Geneva 23, Switzerland -------------------------------------------------------------------------