Dear All,
Please find below my report on the 2nd D4Science TCom meeting held in Pisa from 17 to 19 March. The meeting was attended by around 15 people, mainly technical people from the JRA and SA activities. There were 3 main objective for the meeting:
1) train the project developers on the usage of gCube Core (gCore)
2) present the gCube software process to the project developers
3) plan and prioritise the short-term and long-term functionality to be developed
1) gCore training (Monday)
gCore is a new framework developed during the transition between DILIGENT and D4Science that supports the creation of gCube services. The framework abstracts the dependency over GT4 and simplifies the development of WSRF services. In D4Science all gCube services are expected to be compliant with this framework. Therefore the need for an internal training.
2) Software Process (Tuesday AM)
CERN as responsible for the Service Activity presented the plan regarding the software release cycle and the operation of the production infrastructure. D4Science plans to join the EGEE production infrastructure initially with 4 sites that will be enlarge to 6 by the end of the year (discussion with EGEE SA1 is already ongoing). The slides can be found in:
- http://bscw.research-infrastructures.eu/bscw/bscw.cgi/d81819/TCom_SoftwareProcess.ppt
Software development guidelines and naming conventions were also presented by ENG.
3) Functionality Planning (Tuesday PM and Wednesday)
There was an initial session to brainstorm on the status of gCube, the missing parts, and the important changes to introduce. Overall, the most discussed topics were:
- re-factorisation of existing gCube services to be compliant with the gCore framework
- update of the information object model to allow the existence the "Virtual Information Objects" (pointers to external sources)
- introduction of a new resource type ("Data Source")
- automatic import of external collections
- missing functionality in the Content Management service developed within DILIGENT (notification, full SRM support)
- re-organisation of the project subsystems (several components must be moved to other/new subsystems)
- need to perform performance testing in a limited testing environment
- preservation of state when upgrading the infrastructure
- known critical bugs in the current gCube release
A second session focused on planning the development activity for the next 3 month (until project M6). The different changes and new developments were prioritised and a concrete plan was defined.
Regarding the exploitation of gLite, it will continue to be as in DILIGENT:
- VOMS: integrated with gCube VO support service for user/group management
- LCG CE: for offline execution of applications (feature extraction, user specific apps, etc.)
- DPM: integrated with gCube Content Management service (to be completed)
- BDII
- WMS
4) Final Notes
- Even if extremely unorganised (as usual) I think the meeting productive. It was important at this stage of the project to train developers on gCore, to explain the planned software process, and to align on a prioritised development plan.
- There is still a different level of commitment between the different partners. UNIBAS in this initial phase is not dedicating enough effort on their activities.
- Some developers involved in DILIGENT, mainly from CNR and UNIBAS, have left the project and new personal was (is being) hired. This may delay some of the activities. gCube has a considerable learning curve!
Cheers,
Pedro
=========================================
Functionality and Requirements
- we must support several versions of the same service in the production infrastructure (to allow backward compatibility)
- SR: will support service versions
- IS: ow other service discover the other services with version
- CM: ACL on content management to support annotation and metadata
- CM: support for ontology (not for 1st release)
- CM: support for gLite storage (missing from DILIGENT)
- CM: support for notification (missing from DILIGENT)
- CSD/CSS ranking issues
- FE: to have a the functionality as Service
- Search: Consistency of search results
- Portal: Submit bug tickets from portals
- Portal: create a common front end library to hide the infrastructure
Plan
- gCore: today
- IS:
. is client: done
. is publisher: done
. util lib: in gcore
. is ic: refactor
. gLitebridge: before M6
. notificator: refactor
- VO Management:
. common library removed
. UGMS postponed after M6
. credential renewal -> re-factor and bug fix
. authZ -> re-factor
- BMM
. all -> re-factor
- VRE
. most are done
. deployer: refactor + new func.
. vre manager: refactor + new func. 3 WEEKS
. sw repository: new 3 WEEKS
. portlets
. vre modeler: before M6
- Proc Management
. gLite Job Wrapper: install in a separate container and then register it as a external RI. and MGVI can use it.
. PES: usage of workflow to support system process to warm up the system
- CM
. libraries should be easy to refactor
. Storage Man is high priority
. 2.5 weeks fro re-factoring because they are still learning
. notification is high priority
. replication can be after M6
There are minutes attached to this event.
Show them.
