Notes from IE Teleconference Call Oct 18, 1999 This summary is taken from my hurriedly written notes, so if anyone has any corrections, additions, or requests for clarification, please email me. For instance, I did not get all the names for the NAVO contingent. Participants: Doug Fein, John Melchi (NCSA), Roman Markowski, David Bernholdt (NPAC), Cherri Pancake, Ken Ferschweiller, others (NAVO/NACSE), Derek Moses (ARL), Tim Fahey (MHPCC), Charlotte Coleman, Marlon Pierce (ASC). I started off the meeting with a brief statement of purpose. The goal is to attempt to identify a common list of features that all centers would like to have from pieces being assembled right now for various centers. This will lead to a presentation to the program office and a request for funding. We are not attempting to override any current, funded projects, or ask for centers to fund any project right now. Next, we had brief presentations on currently funded projects. First, David Bernholdt gave an overview of the IOE project at ARL being developed by NPAC and NCSA. David’s slides were posted to the RADB mailing list. Questions followed. I asked David to clarify how Tango would be integrated with IOE. IOE will provide access to Tango. I also asked Doug Fein for a description of the user interface. This will make use of XML and XSL to allow the individual user some customization and some history features. NCSA will demo this at SC99. Charlotte asked for a clarification on slide 8 of David’s presentation. I then gave a presentation on two ASC projects. The Training Management Database System was funded by ASC and written by NPAC. Allows students, instructors, course administrators access to course information stored in databases. I also mentioned ASC’s secure intranet and extranet activities, kerberized Apache module, and Information Environment initiatives. My slides were posted to the RADB mailing list. Cherri next described efforts at NAVO for building web interfaces to databases for S/AAA’s. She emphasized that it was essential to take the end user into account and build something they would want to use. One interface for all S/AAA’s at all sites will not work. The way to proceed for web access to DB’s was to start from each particular database and the individual users and design from there. This will determine the way to proceed with middle tier design. It would take multiple interfaces, one for each site. Doug Fein pointed out that XML could be useful here since it can be used to customize to each individual user. Cherri pointed out that we still had to design for the users. It was essential to design a good interface, which XML alone won’t guarantee. We then attempted to identify goals, common features. NAVO will be building more interfaces for other users. Derek suggested we focus on interoperable parts. Tim identified 3 types of information he would like to have browser accessible: user data, kerberos principal, and user information. Also said he was interested in the other functions presented in by each site. Charlotte pointed out that an important goal was to increase accessibility of information within each site. David @ NAVO said that he had been part of two working groups for building web interfaces, problem was each site had data in its own form. Charlotte said we did not want to change the backend data structures, but instead have a different interface for each site. Charlotte asked Tim to describe what he reported to the program office. They have raw info such as expansion factors, CPU usage, info on Challenge Users. Currently have info in MSAccess DB. Want to make reporting easier. Also have training information on their web site that they would like to incorporate. Help desk information is stored in Oracle DB. Would be nice to have a common way of reporting to the mod office. Was interested in account information, allocations. Would like to know which users have accounts at other centers. NAVO’s interests were a) user services, b) system administration, c) program management (such as financial data). They basically were in agreement with Charlotte’s proposed features. They are moving forward on these things already, one piece at a time. Derek @ ARL referred to David’s presentation on ARL’s interests. Also pointed out that much of ARL’s data was not in a database. ASC’s wish list has been given already by Charlotte in her presentation to the directors. Cherri identified four categories of data that we had discussed: 1) basic data like allocation and utilization data, contact information, 2) document repositories, 3) management information (project status, milestones, timelines), and 4) compressed, high volume data. The last is mostly scientific data and did not need to be considered here. We then went through the categories and suggested who would be interested, would want access. Allocation and utilization data would be desired by S/AAA’s, Principal Investigators, CTA’s, program office, HPC user community. All sites were interested in this. It was pointed out by NAVO that there is a potential problem. If 500 people simultaneously hit the database/webserver at a site, it could swamp their system. Might not want to give everyone access. I pointed out that since we were asking for funding, we would include necessary hardware for each site in the funding request. There was a question on how all of these users would access the DB since there were only a limited number of user licenses. The idea is to run everything as an application account. The users interact with the middle tier, the application account interacts with the DB directly. Each user does not need his/her own DB account. Category II was next discussed. This includes training materials and PET documents, which would be accessible by all sites. Question then arose on how the databases would be populated. We will give the user (with sufficient access permission) the ability to add his/her own data. Some may be automatically updated as well. David @ NPAC mentioned that he was worried about adding data that was in MSAccess DB’s to the system. Weren’t sure how to have an end-to-end kerberized system with Access on the back end. I suggested that we not include this for now, concentrate on data in Oracle DBs. Phone phatigue (fone fatigue?) had set in by this time, so we identified topics for the next meeting. They are 1) the user interface, 2) making a final list of common features, 3) making a final list of requirements, 4) identifying hardware and software requirements (things we’ll need to purchase and thus things we’ll need to put in the funding request, and 5) an estimate of the amount of money needed to fund the project.