· INFN: Gaetano, Massimo, Enrico
· PPARC: Paul
· CERN: Jan, Maite, Lionel, Piotr, German, Julian, Olof
· Paul: report meeting yesterday. Try to get a coherent LCFG distribution from Edinburgh. What is the timescale? Jan: from the testbed schedule we will have to have delivered by first week of November. Paul: my own view is that it’s probably not worth to do synchronization by then, it’s too early; at the meeting they had yesterday in Edinburgh they agreed to have a deadline the 1st of December to have a stable version of LCFG stored in its new cvs repository . Jan: the changes we have done are rather minimal and we are quite interested in some new objects from Edinburgh (for example, the network boot object from Alastair). Update-object is then most complex one.
· Paul: Alastair has done quite some work to modularise update-object. But it is quite a state of flux. Since our last meeting we have actively setting up CVS. At the same time we have a RH7.1 upgrade. The update-object will probably not be finished before December timescale.
· Jan: ok, if we cannot synchronize update-object because it is in an unstable development state, it is probably not worth the effort to try to synchronize at all at this point.
· Paul: we will incorporate the CERN changes in their CVS repository.
· Jan: good. It would also be good if you open the access to the CVS repository so that we can have a glance from time to time.
· Paul: the public CVS is currently not open but we expect that to happen within two weeks. We have quite some interest from other external institutes (ANL, etc.).
· Jan: danger if we incorporate other institutes and they drive the design of LCFG to a different way of the one we want.
· Jan: bug-tracking should go through bugzilla and changes go into the EDG CVS repository.
· Jan: medium term migration from LCFG to NMA. My view was that this should be a smooth transition.
· German: that is not clear at this moment. The migration from one testbed release to another may not be smooth. The development for testbed1 should now be turned to pure bug-fixes.
· Paul: yes.
· Gaetano: does this mean that we don’t have a path to grow from existing system to the future system. Will we have to start from scratch? Can we develop a roadmap for the transition? It should be better for the users.
· German: no we should learn from LCFG and try to develop from that experience. For instance, the objects could be integrated in future Software Packages.
· Paul: I think this should be one major point for the next WP4 workshop?
· German: we should try to work out a plan like that for the next workshop.
· Paul: I’m not sure what the integration of CCM and LCFG will bring us. It is probably a wasted effort.
· Jan: conclusion: we will synchronize in December (Edinburgh deadline), as it is too late to deploy this to the testbed, we keep it as it is (trying to “sell” the installation via the added functionality), and still maintaining the PM9 datagrid version and fixing its bugs. Core code in Edinburg; new objects written during integration/validation will be incorporated if they are useful for most of the people. The bug tracking will be using EDG Bugzilla. But bug-fixes should be done in a compatible way. No new functionality from Edinburgh will be added to the testbed release.
· Paul: major changes will be in the installation system. There are no changes in the object interfaces. The core LCFG will reside in Edinburgh while new objects can be maintained by others.
· Olof: does it make sense to integrate LCFG and CCM or is better to focus at working in the future architecture and next release?
· Paul: a quite a lot of work for this and it is not clear whether it’s worthwhile.
· Lionel: of course we want people to test it. For the integration with LCFG I don’t think there is much work on our side. There are very few changes required on the CCM side. The question is: do we want to do it for all objects or only for new objects.
· Paul: our roadmap is to put out large systems next summer. This means that our PM9 is about January.
· Jan is the effort needed? As far as I can tell we only need fairly simple LCFG objects to install and bootstrap CCM and configure it.
· Paul: that’s correct. The hardest part is probably to get things working at boot-time.
· Jan: with Piotr we had a first look at this. Bootstrapping CCM should be similar to the bootstrapping of LCFG. A single command line argument. Most of the code seems to be in place.
· Lionel: I had the impression that the biggest part of the work was cleanup in LCFG and a daemon for notification.
· Paul: correct there was some re-factoring in the LCFG adaptor. The CCM does not support the context mechanism. Lex is playing with it. The second thing is a move out of functionality out of the adaptors. The third thing: two small bits of code that will match the API between the CCM and the LCFG objects: notification and adapt.
· Lionel: the object to bootstrap the CCM is trivial and should not be discussed here.
· Jan: my conclusion: we cannot make any sensible CCM shipment before November. So the option is to write the new-style objects after December. I can volunteer to write the CCM object. Somebody needs to look at the notification daemon.