Meeting-Poznan-29aug05
From GEANT2-JRA1 Wiki
Contents |
[edit]
Venue
Poznan Supercomputing and Networking Center
Noskowskiego 10
Poznan, Poland
Conference room no 14
[edit]
Attendees
- Roman Łapacz (PSNC)
- Maciej Głowiak (PSNC)
- Szymon Trocha (PSNC)
- Loukik Kudarimoti (DANTE)
- David Schmitz (DFNm)
- Joe Metzger (ESNet)
- José Manuel Macías (RedIRIS)
- Maurizio Molina (DANTE)
- Martin Swany (UD/I2/..)
- Verena Venus (DFN Erlangen)
- Roland Karch (DFN Erlangen)
- Giorgos Pallas (GRNet)
- Nicolas Simar (Dante)
- Jeff Boote (Internet2)
- Eric Boyd (Internet2)
[edit]
Goals
- Wrap up prototype phase 1. Last integration, tests and necessary updates (the system should be deployed by selected networks beforehand).
- Work with JRA5 representative to identify plan for AA.
- Start working on the MP for (RRD, BWCTL) and MA for (IPPM, BWCTL), as well as the multi-domain P2P aspects of lookup, and the AA service.
- Plan development activities for prototype phase 2 and 3.
[edit]
Workplan
[edit]
Day 1, 29 August
10-17
- Finalizing the schema for MA and LS
[edit]
Summary
The agroup agreed:
- Use Normalized metadata with references.
- One can either have a key in metadata or subject/characteristic/parameters.
- Use metadata to describe operations like transformation and selection.
- Investigate hierarchical relationships with parent/child for ease of reading.
[edit]
Day 2, 30 August
9-17
- LS discussion
- JRA1 feedback
[edit]
Summary
- Lookup Service
- Class diagram
- Maybe omit LookupServiceAccess and converting into org.w3c.Document inside of it. Use just LookupServiceEngine instead.
- Change "join" into "register". "join" is related with Jini
- Storage schema
- Use canonical representation
- Use metadata and metadata inside data
- <metadata>service description</metadata>
- <data><metadata>interfaces</metadata></data>
- LS will look through the data and return metadata+data
- Think about storing Key as well
- Response shouldn't contain the request (LSQueryResponse)
- Use message id (request) and id + reference-id (response) instead
- Needs schema changes and implementation (reference id)
- no multiple request (each response follows the request)
- LSRegistrationResponse
- Key - perhaps AccessPoint
- Error = result code (need some schema changes)
- Correct the the schema (modify JZ and MS proposal)
- Modify examples on CVS (one representation of storage schema, no request copy in responses, use of reference-id, example of "key" value)
- Class diagram
- Wiki structure (strawman shown by ST)
- Working docs should not be in the perfSONAR section. There should not be only finalized documents.
- Deliverables in JRA1/Documents section.
- Meaningful page(document) names.
- ST to create new Wiki structure and be a reviewer of perfSONAR section.
- NS to review current documents section when the new Wiki structure is ready.
- ST,NS,JD to work together to improve the Web quality.
- Code reviews
- Assign reviewer or tester for each piece of code to check code quality, make sure it does what is meant to do, understand the code, clarify comments.
- When the code is not following coding standards the reviewer should notify the author. If this is a minor change can alter the code.
- Need for release engineer (packs software, CVS tagging) and quality assurance (runs tests, reviews documentation if it matches the release)
- All to read coding Standards.
- JB to send reviewing guidelines.
- PSNC to write tests.
- Reviewers' assignment:
- JB
- ANT script
- Objects (Java representation of schemas)
- Release engineer
- LK
- MessageHandler
- RRD Access
- MG
- RRDEngine
- RL
- WebService interface
- MS+JZ
- Client
- XML Lookup Service Engine
- DS
- Schema documents
- Regression test
- GP
- Measurement Archives
- Commons
- Quality assurance: run tests (with the help of JZ)
- JB
- Taking decisions
- Clear objectives
- Allocate time for a topic
- At the end of time mention the options: do you understand them? do we need some time?
- More weight on the people working on the topic
- Stick with previous decisions
[edit]
Day 3, 31 August
9-17
- Work with JRA5 representative to identify plan for AA.
[edit]
Summary
- JRA1 and JRA5 representative discussed how JRA5's operations can be useful for its AA needs. The result of the discussion has been summarized and send to JRA1 and JRA5 mailing lists in this document. JRA5 will discuss it during the next week.
[edit]
Day 4, 1 September
9-17
- RRD schema modifications dicussion
- Plan development activities for Prototype Phase 2 and 3 and onwards through October 2006.
- BWCTL
- IPPM
[edit]
Summary
- RRD schema modifications (deadline 9 September)
- JB to change MessageHandler
- MS to provide example instances and schema for config file
- LK to modify ServiceEngine
- RL to modify RRD interface
- CNM client integration
- The code from mid-September will be a "stable" demo instance used by EGEE and CNM client.
- JB+LK+MS to finalise the code for "stable" version until mid-September.
- DFNm to have the CNM script client ready by 21 Sep.
- CNM tool ready for data from GEANT and UNiNet by 21 Sep.
- Lookup Service discussion
- EB said there could be several Lookup Service phases: database manually entered (static) enabling making a query to pull data out; service auto-registration; ability to see other look-up services (can be p2p or something less than p2p).
- JM said base look-up service was there (a MA can tell you what it got) and added taht from an aggregation point it should have said: which are the MA in a domain, which are the other.
- Two axis for Lookup Service Development
- X-Axis
- query static data in the MA.
- query static data in a stand-alone system (the LS).
- query data dynamic data in a stand alone system.
- Y-Axis
- how to find things in a single system.
- how to find things in a single domain.
- how to find things across domains.
- how to find things near to a path.
- X-Axis
- Implementation to December
- 1st step
- Proposal of x-query expressions for the Lookup Service.
- Implementation (basic functionalities: query LS with static data in the database).
- 2nd step
- Implement registration of a service (MA) to the LS and store the information into the DB.
- 1st step
- Implementation of the LS (MG)
- Extension of the client to use it
- For the deliverable, strawman proposal for the LS design: JB help to break down work into several items, MS to help. Edited by MG
- Registration/deregistration
- Keepalives
- Data reduction
- Multi-domain : how to distribute the data (p2p, synchronisation)
- Bootstrapping
- Measurement Point service
- Message first proposal. (MS: mid September, two weeks of iteration on the proposal checked by OWD, BWCTL and passive people).
- Ping MP (2 week to implement with generic executor). Mid October (JB+JZ)
- BWCTL MP (after 2, treated as a one-ended test). Start Mid-October, end early November-Mid-December. (VV + JB as support and knowledge transfer for the Implementation).
- DFN IPPM MA (anytime). Goals: retrieve data out of the existing data store (read-only). Mid-December (RK + JR).
- LK+RL to work on the SNMP MP.
[edit]
Day 5, 2 Spetember
9-12
- Plan development activities for Prototype Phase 2 and 3 and onwards through October 2006.
[edit]
Summary
- Schedule a conf call at the end of December to evaluate on which part of the project the redIRIS and GRnet new developers will be working.
- ST to organise next prototype conf call (Thursday, 8 September).
- Discussion on the next design deliverable
- ST to prepare deliverable ToC (8 September).
- Start on Wiki and when reached substantial amount of content move to Word document.
- JD+ST to write the introduction and the description of the services from the GFD.
- NS to write abstract and conclusions.
- AH to write choice of technology chapter based on his article.
- MS to create UML diagrams for the protocol classes (Thursday, 8 September).
- ST to ask JB if he can contribute on the messageHandlers.
- (all) First version of the Deliverable on Monday at 19th of September.
- (all) to reviewbefore the last week of September (non final version).
- ST to prepare deliverable ToC (8 September).
Back to JRA1 events
