Confcall-prot-24jun05

From GEANT2-JRA1 Wiki

Contents 1 Agenda 2 Minutes 2.1 Attendees 2.2 Discussion 2.3 Actions

Agenda

1. Discuss status of Pending Actions
2. Discuss issues
   • Message type taxonomy
   • Discuss package structure proposal
     • Agreements on location of classes being worked on by Jeff
     • Agreements on location of convertor classes being worked on by Martin
   • Discuss interface parameters between ServiceEngine and MessageHandler
3. Discuss next actions

Minutes

Attendees

Jeff Boote (Internet2)
Eric Boyd (Internet2)
Martin Swany (UoD)
Susan Evett (Internet2, scribe)
Loukik Kudarimoti (DANTE)
Nicolas Simar (DANTE)
Roman Łapacz (PSNC)
Szymon Trocha (PSNC, scribe)
Maciej Głowiak (PSNC)
Jerome Durand (RENATER)
Giorgos Pallas (GRNet)

Discussion

Status of Actions from last phone call

• RL
  • Finish Logging - Done
  • Work on using SAX Parser to read config files - Not Done - waiting for MS to finish
  • Look into latest SAX based class structure - Done
• GP
  • Make xml generated by client compliant to schema - 75% complete - need guidance with example instances
  • Work on completing client specifications - work is already done and is on the wiki, LK and JB to comment
• MS
  • Work on converting objects to XML - Done
  • Move NMWG cvs repository so that its accessible by perfSONAR
  • config file: work on parsing config files
• LK
  • Look into latest SAX based class structure - Done
  • Work on MA Service Engine logic based on this class structure along with RL - Started
  • Send work on config file to RL, JB and MS - Done
  • Sort out issues with Logging and System properties faced by RL - Done
• JB
  • Finish first implemenation of Message Handler - work started, some issues noted: need taxonomy of message names, need for serviceEngine factory, issue with presence of vector of metadata and data objects in the sonarMessage and access to these.
• AH
  • work on client specification along with GP - work is already done and is on the wiki, LK and JB to comment

Pending Actions from earlier phone calls

• NONE

MS posted to Wiki a new page called LS protocol. He had a few questions for the group. This is fairly similar to the GGF NMWG approach – a bit less general to get the group off the ground for the prototype but he had a few issues. The schema for messages assumes a uniform protocol for message typing – which may or may not come to pass. He listed a few items that were included and asked if everyone was comfortable with the term ‘subject’. LK was comfortable with it but asked to unify the terms – AH had not been using the term ‘subject’ up to this point. LK asked the group for input; JB asked what the distinction was between subject and characteristic. Within a single subject (node, link, etc.) but there are characteristics on that node, link, etc. Subject for active measurements (OWAMP, etc.) is the host pair, for example.

LK asked what schemas have been posted; MS reported just one document, right under LS protocol (only one there). Subject is an instance of an address, service subject (assuming using Lookup Service protocol to query a Measurement Archive about the status), etc. Lookup Service protocol – can bootstrap a working Measurement Archive without having a working LLookup Service. LK asked if this worked for all messages in the protocol or just the query; MS said he hadn’t worked on that but there was no reason this couldn’t be the basis for that. Attribute type would change based on the different type of service. Loukik suggested that the group look into the schemas and comment back. LK, MS, and RL will come up with specific examples for the Lookup Service.

Messages to Measurement Archive - decision on usage of keys, what keys represent and exact message sequence (All). Want to keep the number of conversations to the minimum – a key-based system might not be necessary. If a key was previously obtained, you don’t need to get it again. The key must connect to parameters that remain static – keep the time parameter out, for example, since it changes constantly.

JB had a different opinion re: what could/could not be part of the key. He felt it was just an optimization for the end-point. It could encode all the fixed portions of the request – the user could wild card all the items that are not necessary. This allows the archive to do a pre-query on the data that matches to the key; the key could just encode the fixed portions of the initial data query – then the Measurement Archive doesn’t need to support it at all. MS agreed – he implemented a similar system for Planet Lab – serialization of the relevant metadata. He felt that time should be separated out, though.

JB suggested getting the index numbers for the key in before the actual query comes through – for the prototype, at least. He wanted the key to be completely opaque to the end-user. LK summed up the changes: serialization of metadata request dependant upon the Measurement Archive (the client doesn’t need to understand the key at all). Key will be the absolute path to the filename where the data is present.

JB proposed that, whatever’s in the key is totally dependent upon the Measurement Archive you’re using. He offered one example but noted that even this is not ‘fixed’ – the set of metadata the Measurement Archive needs to quickly find the files requested. Some fixed fields, some wild card fields (such as time) – the key maps to some query to create a new table so all requests go to this new table. RL asked how long the key would be valid – he agreed that the key could be a path to an RRD file but how long should it be valid? LK felt it was possible to reuse the keys – request been two routers, for example, the request includes max/min, you might feel it is worthwhile having that key run longer. You can have wild cards for lots of things (not restricted) so you might want to let a key be valid for a week. JB suggested putting an expiration time on the key; let the Measurement Archive control that date (how long). From PoV of the client, some of this data could be visible – timestamp, etc. – but there needs to be a string inside the request that gets sent back to the server (that is NOT readable by the client).

RL asked whether the group needed to concern itself with the validity of the key for the prototype. JB agreed that he wasn’t too fixed with the validity of the request – if the request is for data not currently collected, the message returned indicates that the data is not available. RL agreed – for the prototype, group is not concerned about the validity of the key.

Group agreed that a sufficient metadata request does not require a key – an optimization of option 1; simple enough to do both. RL felt that option 1 (client gets a key all the time – if client takes a key, it can use it all the time for the same data). JD did not agree entirely. JB proposed that the group did Option 1 (full control flow) and, for phase 1 of the prototype, the key could be nonsense but the group would do the full flow. They could use this to optimize the system for Phase 2. LK was thinking of expanding the scope – he’s pushing for a more simplistic interface. JD asked what would be more simplistic; LK felt that the client needed to be more intelligent – another line? Request with more parameters. (missing data for 5 minutes)

LK noted that at the end of stage 2 the client has 2 options; RL agreed. JB clarified that, when the key and metadata are presented, the key has precedence in future requests (that incorporate some/all of the metadata in the initial key request).

Actions

• RL
  • Analysing SAX code on parsing config files
  • change structure of package tree along with LK
  • continue to work on Service Engine along with LK

• GP
  • Update client to use messages which are completely conformant with the schema

• MS
  • Work with Jeff on metadata chaining
  • Work with Jeff on message taxonomy
  • comment on package structure

• LK
  • Work on Service Engine logic and implementation
  • Work on Service Engine structure along with RL
  • Work on moving into new package Structure along with RL
  • Send task I document to Jeff for work on message taxonomy - DONE
  • Look into client specifications on the wiki and see if they are ok for phase I

• JB
  • Look into client specifications on the wiki and see if they are ok for phase I
  • Comment on package structure
  • work on taxonomy of messages along with MS
  • work on chaining of metadata along with MS
  • work on breakdown of message handler, class-diagrams and implementation to satisfy atleast one type of request

---

Back to JRA1 events