WP3 development

Europe/Zurich
Budapest

Budapest

Steve Fisher (RAL)
Description
The various WP3 sessions at Budapest will be treated as a development meeting for members of WP3 to plan, discuss and work togther on the developement of ideas and of code.
    • 14:00 17:30
      Monday - Security
      The following points emerged: Log4j needs documentation for users MDS 2.2 should be tried WP2 want call backs in the API API timeout in produceer is not implemented PGRADE apps crash with R-GMA Nested bloacks are not allowed in PROVE The libwww problem has not been reported change pop / count to allow buffering move multiple rows between servlets Pulse - lacks documentation Web interface for Pulse would be nice XML configurator may be needed VOMS sounds useful
      • 14:00
        Introduction 40m
        Discussion of aims and agenda and the current status What we need to do to address quality issues
        Speaker: Dr Steve Fisher (RAL)
      • 14:40
        R-GMA at SZTAKI 30m
        This should include progress of integration of GRM into R-GMA and a review of Pulse and possible directions.
        Speaker: Dr Norbert Podhorszki (MTA SZTAKI)
      • 15:10
        Security 2h
        This will be in three parts: - give the current status - authorisation for L&B for release 2.0 - to include mutual authentication of components - authorisation in the future
        Speaker: Cornwall, L (RAL)
        transparencies
    • 09:00 12:30
      Tuesday morning - new directions for R-GMA
      Heriot-Watt Ideas - Minutes =========================== Presented overview of current design for R-GMA and it's problem domain. Tried to identify the different types of producers and consumers within a Grid. Identified that between the different types there are primary and secondary producers. Primary = database producer, stream producer/snap-shot producer Secondary = republish tables published by various other producers in the Grid What is the meaning of registration, and how producers are found? Do we need to consider whether to provide for lossy and lossless communication? Will OGSA work with the Heriot-Watt ideas? - Minutes ==================================================== OGSA and R-GMA. We must follow the OGSA direction as that is the future! Not set in stone yet. OGSA may change its direction. Different views on Registry and State management between GMA and OGSA. Xquery is recommended for adoption, as per the OGSA direction. Registry content. Should we be compatible with other OGSA services? A warning to us (well, R-GMA) MDS and OGSA's ideas are converging and heading in the same direction as R-GMA. Security. No clear direction being shown on security yet. Watch this space!
      • 09:00
        Heriot-Watt ideas 2h 30m
        Explain Heriot-Watt plans and ideas (using the existing terminology) - At the heart of the proposal is a producer cache of the latest tuple for each primary key (where by primary key we mean excluding the timesatmp) -Consider wether we should have many Producer (Publisher) APIs or just one or ... - Consider overwite mode for the Producer (Publisher) API - In what circumstances does it make sense for a database to do streaming? - "Pluggable Producer" for WP1 and 5 - Progress on the persistent lightweight producer
        Speaker: Andy / Werner (Heriot-Watt)
        transparencies
      • 11:30
        Will OGSA work with the Heriot-Watt ideas? 30m
        We need to make sure that there are not incomatibilites between any new direction and OGSA.
        Speaker: James (IBM-UK)
    • 14:00 18:30
      Tuesday afternoon - Registry and Schema
      With respect to registry and schema persistence: Four issues were agreed to be important 1. schema topology 2. update frequency 3. unique table identification 4. failure recovery. The idea of using the 'gossip' architecture with each registry having a list of other registries, possibly with an appropriate ordering in event of failure of the first. In the request of new table names, name conflict resolution a serious problem. Qualification using namespaces for registered producers of information a part solution. Responsibility of naming and choice and prevention of conflict may be directed to Virtual Organisation (VO). The URL could be used as a possibility of name qualification of a table name. With respect to EDG Timestamps: could prevent loss of up to 1/2 seconds every 2 years.
      • 14:00
        Integrating the time stamps 30m
        This should address how the time stamp work is best introduced, the format of the time stamp in MySQL, how to ensure that the time stamp is always set - is the current API OK?
        Speaker: Coghlan, B (TCD)
      • 14:30
        How to handle dynamic persistent schemas 20m
        This is to allow user's to publish what they want.
        Speaker: Taylor, P (IBM-UK)
        transparencies
      • 14:50
        How to handle registry persistence 30m
        Speaker: Taylor, P (IBM-UK)
      • 15:20
        How to find the server locations 30m
        A dynamic list?
        Speaker: Magowan, J (IBM-UK)
    • 14:00 16:00
      Thursday afternoon - planning
      The following points emerged: We could have benchmark jobs to help disentangle the application performance from the Grid performance and thereby spot problems. Prove is for parallel systems not distributed. So it is not suitable for analysing the performance of R-GMA. NetLogger will be considered instead. Need to define what will go into first increment, what should go into the second and what should be left for later.