Aug 23, 2007

Agenda for today's call

Infrastructure deployment Deployment (Bobby, Micah)

1. SFASU - Bobby has not received the hardware for this yet. There will be a 2-3 day turnaround. Bobby is going to try to speed up Capricorn. SFASU is next in line.

1. Caltech/Florida/Mich - Mentioned. Reasonable success reported on this front.

1. Vandy campus- There still working on getting imaging working on these nodes. Cluster imaging is working, it just needs to be applied to the depots in question. There are 14 depots available.

What they're working on for REDDnet is moving away from disk imaging and toward making an L-Store appliance. Right now, one of the 4 drives on a node used for the OS. They've developed an approach that uses a 4GB flash drive that attaches via USB and which is used for the the OS (and IBP server, L-Store, etc.). Once the flash drive a approach is in place the 4 main drives are just they're for storage/metadata.

Bobby doesn't think we need to travel to get the remote depots up. If local people will do the minimal work - configure the KVM switch and the power strip - then we can do the rest remotely.

1. TeraGrid - Nothing discussed on this front.

L-Store/Nevoa Software Development (Larry/Hunter)

1. Viewing Software - Larry sent some details about this to PR but we haven't done much to work it out yet. They're creating a nine panel model for SC that Vandy wants to use with this software. The Vandy guys have examined the Google Map API and think it looks good.

The SFA folks think they can contribute on this, but they aren't sure whether they can get done in time for the America View Fall meeting

1. resource 0 problem progress? They can't reproduce the problem. This is a concern since it's did seem to be a real problem.
2. Where do things stand with StoreCore? The version we're working with now has fixed a couple of issues. Hunter noted two changes to the SC: it now has a database back end and they've added support for dynamic LUNs, which are criteria based. Dynamic LUNs are based on criteria (a stored query) that the administrator has supplied.

Diana hasn't done anything with SC yet; she's working with L-Store at the moment.

1. asynch reads, iolib for CMS?
2. SFASU experience
3. FACIT experience - Scott Smith has L-Store/Nevoa working after working with Larry. There was a question of whether StoreCore is able to synchronize multiple SC servers. People can deploy local SC servers to manage private resources and import all the public information.

Annual Report Status (Paul)

Paul has started the report in FastLane. It's unclear how much we have to account for work on the project that wasn't funded by the NSF. Paul is going to email the program manager to find out.

User Reports

1. AmericaView (PR)

Nothing new to report, aside from hardware

1. • any progress using VU depots?
2. FACIT (Terry/others)
3. CMS/RHIC (Dan)

Dan has continued to work on the GridFTP plug-in. He has one that works with LoRS. Eventually this will need to be integrated with L-Store. The latency of using Root with it has been bad because of the latency, but there's hope that Root's prefetch capability can be used with an IBP client that can do non-blocking reads. See Alan's work on an asynchronous client below.

1. • gridftp, root, integration with L-Store?
2. Vanderbilt TV News Archive (Bobby)- Still waiting on the LoC to get their node set up in Washington.
3. IBP asynchronous client: Alan is working on a IBP client that works slightly different than what Huadong has done in his asynchronous implementation.

Upcoming Events

1. Library of Congress Storage Meeting (DC???, Sept. 17)
2. I2 Meeting (San Diego, Oct. 8)
3. Supercomputing 07 (Reno, Nov. 11-15)
4. Demo! (CMS, FACIT, AmericaView?)

Discussion of REDDnet resource discovery

Hunter is willing to lead the effort to create a common way of doing resource discovery. A key part of that will be coming to agreement on what we want the requests to look like, i.e. on the scope of information we anticipate needing to access. Issues:

1. What should the low level protocol be? the current one is Java specific.
2. Initial version used http requests, but that might not be right
3. What kind of queries and calls do we want to support? Right now your given a handle to a configured set of resources. It currently doesn't allow for querying on attritibues
4. What type of interface do we need? The scope of the calls?
5. Is there a need for a purely dynamic service, like the L-bone? If we do need such a thing, should that be part of the same thing, should that be part of the same service, or a separate service. If we don't have something dynamic, then it will be a little harder to configure new resources on the fly.
6. In looking at the people who have been using LN, many of the queries are static. The Czech's for example, have a closed system that works this way.
7. Alan and Hunter seem to prefer something simpler than HTTP.

All other business

Meetings for this semester: Friday's 9CDT/10EDT.