Attendees: WP1: Fab WP2: Leanne WP3: - WP4: Piotr WP5: - WP6: Cal WP7: Gareth WP8: Jeff (except first morning) WP9: Annalisa ( -"- ) WP10: Johan ( -"- ) WP12: Erwin SCG: Akos External: Lee Sequence diagrams: ================== Fab explained the agreed interface among WP1/WP2 (slides should be attached to agenda page); WP1 only interacts with edg-rm, not with RLS directly. The correct order of requirements checking (including data requirements and outputSE) needs to be clarified -> sequence diagram. BrokerInfo file will be there (see slides); probably the user still has to use it since there is no other way to find out about the location of the closeSE. Def of closeSE: has it to be accessible via POSIX calls or not? One could always specify 'file' protocol to be required. So there might be SEs that don't have close CEs. What are the consequences? SE without close CE: standard scheduling, this data will not be taken into account but might still be used by the job; getAccessCost(): covered; might be replicated to another SE. CE without a close SE: standard scheduling will not take this resource into account; getAccessCost(): takes it into account; getBestFile can take an SE as parameter - but which one? => Action on Leanne: clarify what happens in that case. Currently, we can't support CEs that don't have a closeSE for jobs with input data requirements. How is closeSE represented in GLUE schema? => Action on Fab: find out how it works. WP2 'getAccessCost' is triggered through 'classads functions' as extension to rank. The user has to specify that. If this is specified, no further rank expressions are allowed. Reason: we don't know yet how to relate different values like access costs and free CPUs. We need to experiment with that first. JDL parser will check that. RB will not trigger file replication; getBestFile has to be called by the job. Currently getAccessCost returns accumulated best costs per protocol; there is no way to mix different protocols for different files - this might be considered for future releases. => Action on Fab&Leanne: find out the final API of BrokerInfo. => Action on Jeff: work out the sequence an application has to do before actually accessing a file and potentially provide a script. There is no direct interface among WP1/WP5 in release 2.0; all SE related stuff is triggered via WP2. Discussion of whether gridFTP on a SE is required? Shouldn't be but it makes life much easier for WP2 for release 2.0; so we recommend to make it an requirement for release 2.0. => Action on Erwin: check with iteam whether this is OK. ==================================================================== SE Discussion (Jens & John on the phone): ========================================= WP2 should have a working SE for testing by tomorrow. WP2 client class will be provided by WP5. Jens provided a sequence diagram for WP2/WP5 interaction (should be added to the agenda page). Jens should add all SE client/server interaction into the diagram. Open question: who is going to create the destination SFN (WP5 will provide something that is doing that). => Action on Jens: correct the diagram. File access from without the grid: the SE has to be asked to translate the SFN to an STFN; Jeff is wondering whether this translation is needed all time or only just once - if the SE is doing space management the STFN might change over time; Jeff doesn't want that to happen. ==================================================================== GLUE Discussion (Steven on the phone): ====================================== How does closeSE/CE work with GLUE? Need to look into document. => Action on Steve: find out if there are real procedures of how to make addition/changes to GLUE schema and ask for such procedures if they are not yet in place. Is VO specific information possible in GLUE (like ETT)? Steve will look into the schema and tries to find out. ==================================================================== VOMS Discussion: ================ There has to be a negotiation phase between site managers and VO managers; the VO manager has to provide policy information on how to configure the site (in principle by means of ACLs); how is information on VO policies being distributed? Release plan includes detailed information on what needs to be done for release 2.0; At the next meeting we go through the following usecases: - SE: production manager vs. normal users file access rights - CE: priority scheduling amongst VOs and within a VO. This should be for release 2.1 with full VOMS in place. ==================================================================== The tomcat document discussion is going on among Cal, Leanne, and Akos; an updated document will be posted to the list. ==================================================================== Bob gave an update on EGEE - slides should go on the agenda page. ==================================================================== Follow up of actions: ===================== 807: Jeff should post the corresponding minutes of last ATF to bugzilla. 806: same as 807; would also need shutdown procedure for SEs to keep RCs in sync. We will discuss this issue at the next meeting. - Fabrizio to distribute WP1 document on JDL for EDG 2.0 still open - Test if queued jobs are executed when a site comes back-up: Cal still open - Verify if the EDG job-id could be associated with the jobs at the LRMS (for all supported LRMS: Piotr (sent to list): LSF, Todd (Fab will contact him): Condor, Jeff: PBS (David Groep sent to list), Cal: BQS (Fabio, still open) so that it can be retrieved by site administrator. - Check if there is basic service control (start/stop etc.) covered by OGSI definitions: Yes, it's possible: the factory port type allows to create a new instance of a service and each GridService must implement requestTerminationAfter, requestTerminationBefore, and destroy operations which allow graceful termination; the semantics of termination may vary from service to service. Moreover, each port type can be associated with ServiceData which allow to publish the state of a service. There are setServiceData and findServiceData operations defined. Notification port types may be used to subscribe to certain ServiceData and to be notified on a change. For more details see the OGSI specification: http://www.ggf.org/ogsi-wg. Action on Piotr: check whether Jeff's ideas (algorithm) for ETT can be implemented and by when. ====================================================================== Procedures for API changes: =========================== - baseline API definition is required; ask all WP to provide their external 2.0 APIs to ATF; 'external API' is defined to be all APIs anybody from outside the WP will ever use. (1 week before next ATF) this baseline needs to be agreed upon among all WPs (by the easter ATF) any API a WP wants to use and is not in the baseline must not be used. Volunteer for collecting the contributions: Leanne - if a WP wants to change something in that baseline API, they raise a change request with the ATF (email) - ATF representatives have to give an impact assessment as soon as possible. - The ATF representative of the requesting WP has to track the assessments, try to reach an agreement, and passes the ATF recommendations to the technical coordinator who takes the final decision. - If accepted, the change is fed back into the baseline by baseline editor (Leanne) - Any code that is found to differ from the baseline is subject to rejection; the change will be assessed by the ATF.