Aug 23, 2007: Difference between revisions
Jump to navigation
Jump to search
| (5 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
* P.R. Blackwell, Diana Gunter (SFAU) | * P.R. Blackwell, Diana Gunter (SFAU) | ||
*Hunter Hagewood (Nevoa) | *Hunter Hagewood (Nevoa) | ||
==Agenda for today's call== | ==Agenda for today's call with notes inserted == | ||
=== Infrastructure deployment Deployment (Bobby, Micah)=== | === Infrastructure deployment Deployment (Bobby, Micah)=== | ||
| Line 30: | Line 30: | ||
===Annual Report Status (Paul)=== | ===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 | Paul has started the report in FastLane. It's unclear how much we have to account for work on the project that wasn't performed by people funded by the project. There was no money for people in this project. All the people working on it are funded from other sources. Paul is going to email the program manager to find out. | ||
===User Reports=== | ===User Reports=== | ||
*AmericaView (PR)- Nothing new to report, aside from hardware. There success using the Vandy infrastructure has been spotty. | |||
Nothing new to report, aside from hardware | *FACIT (Terry/Larry) | ||
**Larry has been working with Scott Smith at UCSB and, as of yesterday, has the L-Store/StoreCore package up and running. | |||
**Terry reported talking to Larry Carver yesterday. He expressed a desire to have a group phone call of the FACIT technical/systems folks to talk about getting the software components up and running so that they can start experimenting with it. Terry is going to send out mail to get this arranged for next week. | |||
*CMS/RHIC - 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. | |||
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. | **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. | ||
**IBP asynchronous client: Alan is working on a IBP client that works slightly different than what Huadong has done in his asynchronous implementation. | |||
*Vanderbilt TV News Archive (Bobby)- Still waiting on the LoC to get their node set up in Washington. | |||
===Upcoming Events=== | ===Upcoming Events=== | ||
| Line 53: | Line 52: | ||
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. | 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: | Issues: | ||
#What should the low level protocol be? | #What should the low level protocol be? The current one is Java specific. | ||
#Initial version used http requests, but that might not be right | #Initial version used http requests, but that might not be right. Alan and Hunter seem to prefer something simpler and cleaner than HTTP. | ||
#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 | #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 | ||
#What type of interface do we need? The scope of the calls? | #What type of interface do we need? The scope of the calls? | ||
#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 | #Micah: 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 service as the more static service (e.g. StoreCore), or should it be a completely separate service. If we don't have something dynamic, then it will be a little harder to configure new resources on the fly. Hunter noted that, 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. | ||
===All other business=== | ===All other business=== | ||
None discussed. | |||
Latest revision as of 11:23, 23 August 2007
Attending
- Alan Tackett, Larry Dawson, Santi de Ledesma, Bobby Brown (Vanderbilt ACCRE, in Nashville)
- Dan Engh, Paul Sheldon (Vanderbilt Physics)
- Micah Beck, Terry Moore (UT)
- P.R. Blackwell, Diana Gunter (SFAU)
- Hunter Hagewood (Nevoa)
Agenda for today's call with notes inserted
Infrastructure deployment Deployment (Bobby, Micah)
- 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.
- Caltech/Florida/Mich - Mentioned. Reasonable success reported on this front.
- 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 approach is in place, the 4 main drives will be completely available for the storage of data and metadata. Also, no more disk imaging. This approach supports remote updates of the system software, etc.
- 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.
- TeraGrid - Nothing discussed on this front.
L-Store/Nevoa Software Development (Larry/Hunter)
- Viewing Software -
- Larry sent some details about this to PR but we haven't done much to work it out yet. Vandy is 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 for this purpose.
- 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
- resource 0 problem progress? They can't reproduce the problem. This is a concern since it's did seem to be a real problem.
- Where do things stand with StoreCore? The version we're working with now has fixed a couple of issues.
- Hunter noted two changes to StoreCore's current version: 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.
- SFA experience: Diana hasn't done anything with SC yet; she's working with L-Store at the moment.
- 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.
Setting a Meeting Time for this Semester
The agreed upon meeting time is Friday's, 7am/9am/10am Pacific/Central/Eastern time. Standard coordinates: 510-665-5437, Meeting ID 7333
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 performed by people funded by the project. There was no money for people in this project. All the people working on it are funded from other sources. Paul is going to email the program manager to find out.
User Reports
- AmericaView (PR)- Nothing new to report, aside from hardware. There success using the Vandy infrastructure has been spotty.
- FACIT (Terry/Larry)
- Larry has been working with Scott Smith at UCSB and, as of yesterday, has the L-Store/StoreCore package up and running.
- Terry reported talking to Larry Carver yesterday. He expressed a desire to have a group phone call of the FACIT technical/systems folks to talk about getting the software components up and running so that they can start experimenting with it. Terry is going to send out mail to get this arranged for next week.
- CMS/RHIC - 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.
- IBP asynchronous client: Alan is working on a IBP client that works slightly different than what Huadong has done in his asynchronous implementation.
- Vanderbilt TV News Archive (Bobby)- Still waiting on the LoC to get their node set up in Washington.
Upcoming Events
- Library of Congress Storage Meeting (DC???, Sept. 17) - Terry talked about the fact that this now looks to be much more vendor-centric than originally planned.
- America View Fall meeting (Sept. 19th and 20th)
- I2 Meeting (San Diego, Oct. 8)
- Supercomputing 07 (Reno, Nov. 11-15)
- 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:
- What should the low level protocol be? The current one is Java specific.
- Initial version used http requests, but that might not be right. Alan and Hunter seem to prefer something simpler and cleaner than HTTP.
- 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
- What type of interface do we need? The scope of the calls?
- Micah: 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 service as the more static service (e.g. StoreCore), or should it be a completely separate service. If we don't have something dynamic, then it will be a little harder to configure new resources on the fly. Hunter noted that, 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.
All other business
None discussed.