Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Teleconferences

The first CSWG teleconference will be Thursday, March 7 at 11:00 CST. To attend:

1. Call 1-510-647-3480
2. press 1
3. enter 187514#
4. follow the instructions

The agenda for the first meeting appears below (note that we do not expect to cover all items during the first call):

1. VDT staus report from Alain Roy/Miron Livny
   • when can we expect VDT release
   • what will the release contain
   • how will it be packaged
   • how will it be documented
2. Explanation/dicussion of NMI deliverables and overlap with GriPhyN/iVDGL from Alain Roy/Miron Livny
   • when can we expect NMI release
   • what will the release contain
   • how will it be packaged
   • how will it be documented
3. Discussion of these paragraphs which attempt to put iVDGL Core Software WG in context with NMI and GriPhyN-VDT:

   The NMI deliverables are standard core Grid tools such as Globus and Condor which have been thoroughly tested for interoperability. The testing is done by a group at Wisconsin-Madison.

   The VDT will be based on the NMI deliverables, plus tools and software that is specific to dealing with virtual data. The VDT will be put together and packaged by the GriPhyN VDT team, with again most of the work being done at Wisconsin-Madison.

   iVDGL scientists will be the major users of the VDT. As such the iVDGL Core Software Working Group will work with the GriPhyN VDT team to harden the VDT. In particular the CSWG will set up a test cluster and test for interoperability all elements of the VDT, by essentially extending the testing done by NMI to include the virtual data pieces not part of NMI.

   Questions:

   • Who actually does this interoperability testing? (Need actual names)
   • Where is the test cluster built? Can we leverage what is already happening at Wisconsin-Madison?
   • Where does the money for the cluster/people come from?
4. The iVDGL proposal contained this as an activity for supporting iVDGL software:

   "define and implement a unified and fully inte-grated error reporting framework across all VDT components"

   • Is this a task for the Core Software WG or the GOC at Indiana?
   • If it is a task for the CSWG, what type of error framework do we want?
     • Do we expect users of the laboratory to send error reports to us and we forward them if necessary to Globus, Condor, etc?
     • Who answers error reports? What is the work flow? What quality of service do we expect to provide?
     • What is meant by "integrated" and "unified"?
5. Another item in the proposal is this:

   "equip the VDT with dynamically configurable event logging capabilities"

   • Why? What is going to be down with the information? What is the idea here? What is going to be logged?
   • Do we have bodies necessary for this type of development?
6. From the proposal:

   "extend the VDT with new components required for specific application purposes"

   • Does 'extend' mean we do this for every component any application needs?
   • Does the CSWG review proposals and only add components that are farily generic?
   • What if a componet requires a large investment by a site in deployment and configuration? Or a large investment by the CSWG to "integrate" the component?
   • What if an application absolutely need some component but it breaks some other parts of the VDT (perhaps two apps try to use the same port...)?
7. From the proposal:

   "help users to maintain and trouble shoot the VDT software"

   • Again is this a task for the CSWG or the GOC? Or perhaps it is a shared task?
   • A proposal for this: We use the same model as NCSA. The GOC acts as a "helpdesk". They log error reports and do as much trouble shooting as possible. When issues are deep the reports are assigned to the CSWG and "experts" representing each application work on the problem.
   • Will this be useful, or are the applications simply going to contact their own experts anyway? Are we going to build a support structure which will never be used?
8. Documentation:
   • What about documentation? What are NMI and GriPhyN/VDT expected to produce?
   • If the CSWG is tasked with writing documentation, what type of access will be have to the developers?
   • Is web documentation good enough, or will paper be required?
9. VDT specific issues:
   • Should the VDT distribute CA certificates (public keys) ? If so, which ones? (Note the word is 'distribute'. Whether or not a default VDT install enables the public keys is a different question.)
   • Should the CSWG build and deploy a mechanism that allows configurating of grid-mapfiles? Or is this a GOC activity?