Many thanks to Vesso for taking these. The slides are on the OGF website http://www.ogf.org/gf/event_schedule/index.php?id=1115 ===== Advanced Filter Profile. Steven Newhouse: Overview of the Advanced Filter Profile(AFP): - the purpose of the profile is to define a functionality for scoping of the data returned by calls to GetFactoryAttributesDocument(). The current returned document definition allows for basic filtering by simple inclusion/exclusion of given activities and resources. - the proposed Advanced Filter (for activities) expands the basic filtering by allowing for scoping based on; UserName, Owner, State etc. An HPCBP implementation MAY not support the AFP but MUST return UnsupportedFeatureFault if it doesn't. - the proposed Advance Filter (for resources) expands the basic filtering by returning available resources in per-resource-type records rather than per-resource-instance records. Chis Smith: There might be issues with using String-based jobIDs in the returned data of the AFP calls. The jobID is returned inside EPRs and the EPRs are opaque to the user (the jobID value format as well as its placement within the EPR is service specific). Could we define a specific/standard/commonly accepted attribute for jobIDs as part of the EPRs? S.Newhouse: One option - an agreed upon namespace definition. Action Item - address the format of the jobIDs returned. ===== Application Template(AT). Steven Newhouse: Overview of the Application Template: - the purpose of the template is to simplify the job submission, i.e. the user would not need to specify every detail, executable, parameters etc, when submitting a job. - there needs to be a away of discovering the ATs available at given HPCBP service end point. Proposed way - an ApplicationTemplates element in GetFactoryAttribtesDocument() return doc. containing multiple JSDLApplication elements providing the ApplicationName, ApplicationVersion and Description values. Note: Template names not portable between HPCBP endpoints. - AT usage - provide a jsdl:ApplicationName (optional jsdl:ApplicationVersion) element; may specify jsdl:JobIdentification, jsdl:DataStaging elements; jsdl:Resources elements overridden by the AT. - Precedence of HPCApplication values after the HPCBP endpoint applies an AT to a submitted JSDL is pre-defined. Some of the values will be replaced by values defined in the AT others will be added. Chis Smith: There should be an alternative to 'silently' replacing JSDL values supplied by the user which clash with the values defined in the ATs. There should be a set of Faults defined to allow for notifications of clashes to be thrown to the user. Use the Faults to communicate what is/not accepted Blair Dillaway: Throwing Faults for every jsdl value clash back to user would be a complicated way of discovering what is needed to submit a job. Action Item - address the issue of whether the AT will provide default values which are pre-determined to be overrideable/or not by the user-provided ones or a mechanism for resolving clashes between AT and user provided values which may/may not be accepted by the HPCBP endpoint. ========= File Staging Profile(FSP). Marty Humphrey: Overview of the origins/need for the profile - discussion started mid'07, a draft ready for SC'07, public comment period 4 - 11 Feb'08, the period extended. The FSP based on JSDLv1.0 DataStaging Element. Addition of 'Credential' element, Specification of supported protocols, Discovery, File staging failure exceptions. - Supported Protocols - requires at least one of scp, ftp, http. Mandates username/pass security mechanism, - Discovery - inside BESExtension element return. ===== Kerberos Authentication support. Chris Smith: Overview of the reasons for supporting Kerberos credentials in a JSDL doc: - requirement coming from users of vendors implementing the HPCBP. There is a large user base using; Kerberos as authN mechanism, single-sign-on services built on top of Kerberos and/or large number of batch system relying on Kerberos credentials. - in addition to authN of services, the delegation of access rights is an issue to be addressed - usually the same Kerb ticket is used in the context of job execution so the same will be used for this job's DataStaging so no need to specify the Kerb credential in the FileStagin element of the JSDL. - Kerb authN mechanism is simple and well understood, however, usually is non-trivial to implement/progam for. Blair Dillaway: Need to write a use case doc for clarifying the user need/requirement for the Kerb authN support in the HPCBP.