TMB 25/02/09 cal (CL) vangelis (VF) xavier (XJ) maite (MB) francesco (FG) oliver (OK) steven (SN - chair) massimo (ML) nick (NT) patricia (PM) * minutes of last meeting no comments * action list nothing discussed * proposed changes to DoW for next year steven goes through the doc SN - will circulate revised version to AMB today, will be presented to PMB in Catania. After PMB endorsement details changes to pow happen in April for the commission to then be presented at the review ML - it's an entirely EGEE process? who syncs with LCG? SN - we'll take input now, and formally at the AMB SN - EGI activities - not clear where these activities will be in 15months. This doc will feed into EGI design study deliverable. That doc has changed its date to end of June. EGEE's transition plan will be defined before EGI has defined its transition plan. By end of summer EGI should have set up a transition team. SN - PMB has to endorse strongly and give a full mandate to do these deep changes MB - if we don't manage to do this now that we're all working together it's less realistic in a year. FG - agree more or less with approach and priorities. it's ambitious. plan foresees additional work, so either we can save some resources to do the work, or we have to deprioritise other things. OK agrees - better to manage this upfront than to drop things subsequently SN - are there any components which can be put into maintenance only? SN - product manager will have to balance resources between maintenance, testing and certification. could shrink maintenance to as little as possible. take feedback from Ops and experiments on this. Could fix major bugs but otherwise this is dormant. FG - there are inefficiencies in how we develop software, if we reduce these we can add tasks to the workplan. OK - SA3 might not be able to handle the current change rate while implementing deep changes to the process FG - should aim at more scheduled patches. plan in advance how many releases they envisage for components. ML - on page 4 there is the list of areas of software maintenance SN - these are product groupings. dev teams with functional synergy which means they have to work together. ML - these are areas for maintenance. SN - come from JRA1 description of work. ML - but there are things which have not yet been delivered. eg a functional backend to glexec. FG - SCAS is not in JRA1 DoW. SN - dev activities will carry on where appropriate. Maintenance should be reviewed to see if there are components in a maintenance mode to find out how much effort they need. ML - experiments see glexec not working properly without SCAS. Same group has responsibility for this as for other things. risk is that we get Auth service for end of project. don't want SCAS to slow down because they concentrate on Auth service. there are other mixtures of maintenance and long term stuff. SN - we can change the groupings and see where dev effort is committed to ensure this is ring fenced so things don't slip. then prioritise which components are stable except for bugfixes, and which need functionality. ML - have heard glexec/SA3 interaction was not great. will you have a list of things you drop? FG - can go through down list and see if anything has to be removed. SN - one thing we could do is decide we do CREAM/GAServ but we don't do WMS. action on SN/FG to look at this CL - monitoring service is not there (ActiveMQ) SN - this is operations work MB - but there is no milestone to get applications to move. there is no effort beyond EGEE to further development of this. SN - cal, do you have preference for RGMA or ActiveMQ? CL - we want something that works ML - there are eg dashboards which rely on diverse sources of info. we should ensure new tools can serve the entire community SN - ActiveMQ is where we want to go. a new milestone is to establish an interface a clear API across all services. we can include messaging into this. ML - job monitoring is a specific example. CMS/atlas need this for debugging. don't want to lose this info. SN - what is used now? ML - imperial college monitor from LB. MB - we are discussing with them to use ActiveMQ ML - have to agree what data will be available so existing apps can continue to work. SN - makes sense to have a core messaging system which everyone can subscribe to. MB - some tools may have to change ML - we an adapt to new interfaces but they must provide the data we need OK - LCG-CE, Apel, dCache not there SN - can potentially add these SN - EGI has dev, test and prod experience all in same product team, so prod experience should feed back earlier into dev process. Can foresee collaboration between prod teams and sites. gets realistic prod requirements from experience with mature prototypes. SN - can move effort from PPS to NGI/ROCs. deployment debate on PPS pre-deployment testing PPS use-by-users. SN - when UMD announces a release, this will typically not have already been deployed by an NGI. we need managed rollout afterwards. ML - for SCAS we don't use PPS infrastructure, OK - we do use the pre-production activity. ML - value comes from Antonio etc SN - pilot service seems effective. should not restrict interaction between developers and production. PM - this is very flexible for the experiments. if we can put a middleware change into the computing model of an experiment, you will get feedback immediately. NT - NB there was a change in the last year, there is no PPS infrastructure any more. ML - the developers mustn't do this coordination, it needs people like Antonio. SN - EGI mu has an 'Antonio' role. FG - this was born with the experimental services of WMS/LB. model was adopted for EGEE-iii. sometime you need a population of nodes (eg CREAM) for proper early user testing, developers can't do this. ML - WMS was not really 'alpha', it was advanced and brought this service into production. ** training infrastructure SN -assumption is training infra is part of the prod infrastructure. propose for next year that the t-inf is brought into the same monitoring environment as the prod infrastructure. NT - NB monitoring is strict, otherwise they will be kicked out. MB - are these separate sites? or resources within sites? SN - in EGI there are no separate resources unless an NGI wants to do it. NT - if it's just another VO it won't make any difference. SN - I spoke to robin on Monday and he didn't object CL - i think they are talking about creating an SSC for training. check their plans ** SA2 migration XJ - i haven't read all EGI definition, but as i see there is not much manpower for this in EGI. Do we have to produce all this detail for the transition? SN - the reason why the blueprint is so light on networking is that they see this as being undertaken by NGIs or by existing NRENs. Therefore only thing in EGI.org is the coordination. XJ - the NGIs can contribute. to give to NRENs is to have a conflict of interests - you ask them to check themselves. XJ - you propose 3 milestones for a small activity. i propose to merge PM12 with ENOC deliverable on PM11 and to merge PM15 and PM18 into milestone on PM17. it will be easier for us to handle like this SN - I'm flexible. concern is to make sure that something documents availability of software is done early so tools are buildable and deployable outside current environment. XJ - i propose to move from PM15 to PM17. SN - send me back a proposed set of changes XJ - if you agree, we should modify the purpose of the milestones. their descriptions. SN - idea is to change 2nd year DoW, not add stuff to 1st. put this into 2nd year. * SSCs SN - what I put was was drawn from Cal's presentation at the AA. CL - various clusters are trying to form their SSCs. all clusters have expressed an interest in doing so. 4 have done quite a lot already. astro, hep, life science, earth sciences. what is written is fine. what is missing is what to do at the next user forum. should make it an EGI style one with Nordugrid and Unicore? PM - do all those roles you mention have to be different? SN - depends on SSC. they could all be one person if appropriate. PM - should we establish this model during year 2? SN - need to move to an 'EGI like mode'. PM - practically, the structure will not change? SN - yes, more a relabelling... CL - support activities will change (do they become SSCs?). Not much else will change. Once the EGI people are known they should contribute. OK - would we have names? SN - there is a commitment by EGI that there is a transition team in place. these people may or may not take on equivalent roles in EGI.org. cannot know because EGI will have no budget. OK - so we cannot necessarily train them... CL -- this needs to be discussed in detail. If they expect me to do it they're mistaken! I'm planning to hand these responsibilities over. SN - understood. they have not budget to hire unless the host nation puts up funds. VF - local NGI application support. does this need to be included explicitly? leave as NGI responsibility? * MCB SN - can be seen as a subset of the TMB. As part of process, look at setting up what EGI calls MCB to coordinate middleware. includes reps from middleware providers, Ops and user activity. Not sure about inviting members of Unicore and ARC, open to advice. would there then be a role from the TMB? FG - i see an almost perfect overlap. SN - only difference is participation of other MCs, and TMB deals with policy issues like a new security policy. TMB should maybe delegate this to Ops unit within EGI org. This may result with an empty TMB. OK - relation between MCB and m/w providers is different to TMB's. could be contractual. could experiment with possibilities. FG - could do more monitoring, not enforcement. ** FG - next year starts at PM13, so PM12 milestones should be PM13. SN - agree FG - as a m/w prov, would like input from Ops and Apps if the contents of the JRA1 milestones are acceptable. * stuff on software provider (page 3). SN - will discuss with Fran/Oliver. Are there more general comments? SN - one assumption in combining cert/dev is that process is highly automated. ETICS is default tool in this space. we're working on a list of what we as a project need for ETICS to support this. SN - once activity management has agreed on tools an process, it's essential that this is fully adopted. These changes need the full support of the PMB otherwise this won't work. Must buy in 100%. There are deep organisational changes, and some people have 5 years of doing things one way. SN - will be discussed at PMB on ?? in Catania. ** AOB NT - on milestones, PM12, remove RGMA. we know that APEL will be earliest ready at July. NT - need to follow up on proposal for service removal/obsolescence. needs TMB involvement. SN - let's check offline and provide feedback on the list. If necessary, can discuss at next meeting.