CVS Usage --------- See image ... Current state is not good: merges are going back and forth between HEAD and R1 branch. Proposal is to merge everything now back to HEAD so that all developments as it should be are on HEAD only. Bugfixes that would involve serious integration issues and interface changes have to be done on HEAD and their fix introduction has to be delayed to the next release. Pure bugfixing is on the branch, merging back to HEAD immediately. In future releases (R1.1, etc) the HEAD needs to be branched if bugfixes happen such that they would be interfering with new features. The HEAD merges happen this week. Documentation ------------- Daniel will do the fireman-java Akos for fireman-c Gavin will have to do the Transfer - not for R1 stuff, but the new guides Ricardo for TS Web UI MAPS ---- all done. waiting for feedback from frederic. Gavin's report on Lyon meeting ------------------------------ - attendees was a mixture of tier 1 deployment people and GDB people - we have shown that we were running reasonably stable for a week which was what we wanted. everyone was quite positive about this. - officially no decision has been made yet q: what was the comment about this and phedex? a: peter elmer wasn't there so none my comment was that it's the same design as the radiant software. people agreed that radiant was a prototype and that we move towards a more maintainable version which this was. - phedex interaction will have to be clarified cms is not talking to SRMs which is causing it a share of issues they don't go through radiant at all which is an issue for SC2. they have to ask to switch phedex off at times... - we need to talk to CMS how phedex could live on top of the transfer services q: how does phedex implement the job fetcher interface? - all i presented is the file transfer service. it only deals with SURLs. - there was a discussion in the afternoon about what goes into SC3. proposal comes from GDB - having shown that this works for a week was a good thing. q: we need to keep this up and running. new boxes? a: talked to james. there was a low bandwidth setup which ran longer. the high bandwidth setup is also there. idea is to have a small setup for tests and then if everything passes, upgrade the bigger one. start including other sites. q: will that not interfere with SC2? a: yes but that runs only for a few weeks. but it can be worked around. we need the boxes on 'back' - they are reorganising the boxes and had problems finding switches and bits of cable.. we need to understand what we can get.. maybe DESY can get involved early. this would help us because of the dcache srm interface testing. infn and in2p3 run castor but the rest run dcache so this is important. - there is also the possibility to use some of the gridftp log mining developed by someone at nikhef. - we need to give the items for monitoring to JRA4. AOB/Discussions --------------- Akos: do we do the SC exercise with the catalog component? Gav: Atlas presented some requirements, nothing new. CMS was not there. Alice said that they would use gLite... whatever they mean. I think they meant glite and not alien. LHCb said they don't have much effort to develop any catalogs, they just need baseline services 'that work'. Krzysztof: Long running calls discussion... (locate) have a separate table or index? Ricardo: rename current 'locate' to 'find' and then do a separate locate. why not just use metadata query MDQuery? with predefined attribute names like size... K: the MetadataBase is implemented but not MetadataSchema P: should be.. Akos: as a separate porttype or as inheritance.. i prefer porttype Ricardo: we had problems with that in MetadataCatalog A: its cleaner not to inherit.. it's cleaner functionality. the reason to inherit was not to confuse the FASBase. discussion on inheritance in the metacatalog problem with FASBase and fine grained authorization - how is the schema secured? how is it done in FPS database? internally..