Minutes from meeting between Ariel and Philipp, Nov. 2007 Please note that DECISION does not mean GSA group decision, but agreement between Ariel & Philipp. Scheduler Interoperation ------------------------ # General # - Basic Interop. Scenario (see slides from OGF 21): Job requirements can not be fulfilled, therefore job is transferred to another scheduler. This means to stay simple, do not cover re-scheduling, monitoring, ...? - This is only about scheduling decisions which will be handed back to the requestor (the "client" in the interop. scenario picture), we are not dealing with job execution and such things. - Instead of handing a scheduling request to another scheduler and getting a decision back, it would also be very handy to execute scheduling "dry runs": one scheduler asks another for possible offers like "can you provide X resources at this time, and if not, what alternatives do you have"? (Can be done with WS-Agreement wsag:createAgreement). This is just a small addition to the basic use case. - A combination of the classical scheduling case and the one mentioned above would result in a number of alternatives in case a scheduling decision cannot be made. - The answer whether a scheduler can fulfil a scheduling request results from a logical "AND" operation with all mandatory SDL and JSDL parameters as input. If the answer is a NO, alternative parameters could be specified in the response, but this is not the No. 1 goal of the interop. # Scheduling instance interfaces # - Scheduling request: SDL + JSDL, Scheduling response: Time info + job info + some info about the execution endpoint + environment-specific stuff, e.g. reservation ID. QUESTION: Format of the response? - Implementation of the scheduling instance interfaces (see Grid Scheduling Architecture requirements draft): + Output a scheduling problem == SLA offer with a specific template --> implies the inclusion of SDL attributes into WS-Agreement. + Input scheduling decision == agreed SLA. QUESTION: Should scheduling request and scheduling decision be transported both via the same SDL instance document or should this be two different documents? - WS-Agreement is very complex. General consideration: a simple interface for reservation can also be used to ship SDL messages in a cases where WS-Agreement is too complex. SDL can be used in different contexts. State this clearly - QUESTION: Relation between domain scheduler and local RMS: Why using WS-Agreement here? Need for a simple reservation API. Addition to DRMAA? Relation to BES? - QUESTION: What should go into the ?scheduling descision?, the request answer? How is this related to the request? How is this related to Attila's work? # Interop. architecture # - Client - scheduler interaction: QUESTIONS: (i) EPS or WS-Agreement? (ii) In case of WS-Agreement, what about situations where client and scheduler are located in the same domain? Easiest case: client sends JSDL plus SDL parameters to primary scheduler, interaction between schedulers is WS-Agreement including JSDL and SDL. Remaining question: what protocol to be used between client and scheduler? Just submit to scheduler or more (like status info, control operations, etc.) are needed? - Client - scheduler: standard scheduling interface needed for requesting and receiving scheduling decisions. - EPS is a good candidate interface for client - scheduler, but only in case you are within one domain. In case of crossing domain boundaries, we need WS-Agreement as a protocol. QUESTION: Can use the same attributes (JSDL, SDL, ...) as in the EPS case? - Be more specific about services and interfaces: Be specific about what is an interface, what a protocol, etc. [ACTION] Revise figure. - DECISION: Interaction between schedulers is only based on time constraints (the realisation, not necessarily the SDL) - DECISION: Within the interop. scenario we just generate a schedule, but do not enact it! - QUESTION: What to put into the inter-domain registry to be discovered by the CSG? Is it likely that there will be local information about resources managed by the different schedulers? Answer: Maybe not. QUESTION: Is CSG the right thing here? QUESTION: What is the meta-information to query via CGS to decide which scheduler is a candidate for processing the request? - Maybe it is also something between schedulers like between the client and the scheduler? Using CSG for intra-domain and CSG plus WS-Agreement for inter-domain? But this is only the case for a scenario where one scheduler wants info about potential time-slots from another one, not for the very simple case of asking whether one scheduler is able to schedule the job or not. - [ACTION, ALL] Read OGSA-RSS documents and compare the required SDL functionality to csg:CandidateQualityProperties. - If we generate a scheduling decision only, why do we need the information from the local GIS and the interface to the sub-scheduler? Why do we need OGSA-BES then? - Faults have to specified. - QUESTION: WS-Agreement: Is it possible to include domain-specific faults into an WS-Agreement message. -> Ask Oliver. # SDL # - PROPOSAL: Modular approach of SDL. Just specify in the beginning in detail the things needed for interop, which are the ?time constraints?. Next important thing is workflow, but the question remains who is going o specify that. WM-RG, ?? - If "time constraints" are treated just as another QoS, there could be another approach then specifiying earliest StartTime etc.: Specify "range", "exact value", etc. and apply this to a number of specific parameters (like done in JSDL). - RESOLVE: Do we use the Scheduling Description Language (i) to describe the interaction requests and descisions between schedulers or (ii) also to carry the scheduling/brokering/? policies? - Start with time constraints: duration (optional), startTime (range, optional), dayTimeWindow (optional), excluding (optional), including (optional) - [ACTION] Update SDL attribute table (see https://forge.gridforum.org/sf/go/doc14026?nav=1) # JSDL Profile # - JSDL profile will be a proper OGF profile doc., take HPC profile as an example. - QUESTION: Do we also need to profiel WS-Agreement? - Maybe a better name is "Grid Scheduler Interoperation Profile". Especially in case it is not just JSDL. - The profile represents an "a priori" agreement on what can be specified, what has to interpreted, and what is taken into account to schedule. - It has to be clearly specified what it means that a scheduler "understands" a JSDL document. We will have some attributes which need to be provided (answer YES/NO, e.g. "OperatingSystem"), other which are not necessary for the scheduling decision, but which should not result in a parser error.