Teleconfence Minutes - 9 November 2005 ====================================== * Participants Michael Behrens (R2AD, LLC) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Tom Maguire (EMC) Dejan Milojicic (HP) Mark Morgan (UVa) Takuya Mori (NEC) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Stuart Schaefer (Softricity) Frank Siebenlist (ANL) Ellen Stokes (IBM) Jay Unger (IBM) Jem Treadwell (HP) Apologies: Fred Maciel, Peter Ziu Minutes: Andreas Savva * Minutes approval ** November 7 minutes approved with minor corrections - Clarify that it is the sophisticated estimation of deployment time is not a high priority. (Per Hiro's email to OGSA-WG ml) (Done) ** November 2 minutes: - Add Manuel Pereira to participants (Done) * EMS and CDDLM, ACS joint discussion - A number of ongoing discussions on the list. There seems to be convergence on many issues. - Remaining discussion points: 1. Where to draw the line in the CDL tree (aka deployment vs provisioning) - CDDLM team to follow up with Jay 2. EMS requirements for deployment - CDDLM team to follow up with Andrew 3. What kind of information CSG (RSS-WG) expects to get from an ACS repository. Or, more generally what kind of information CSG expects to be able to get and from where. - Hiro has started a discussion with the RSS-WG - CDDLM and ACS services should be added to the EMS architectural diagrams - Deployment requests to CDDLM deployment service - Static information about applications to the (ACS) repository - Dynamic information to information services - CDDLM services could provide information about which applications are installed where - (And optionally, if needed, an estimate of deployment cost--- keeping in mind previous discussions that such estimates are unlikely to be accurate.) - Deployment versus provisioning requirements (Or, where to 'cut' the CDL tree. Above the 'cut' point is deployment---assumed to be a relatively 'light' operation---and below is provisioning---assumed to be more heavy-weight.) - Deciding the cut point is orthogonal to CDDLM---it is policy or best practices and is therefore a system choice - Information (metadata) to help in making the choice could be added to the CDL as mark up - CDDLM implementations have walked the tree fairly far down (to the hardware) for deployment - CDL may be sufficient to express both deployment and provisioning. But it is an open issue if these two activities can, or should be unified in this way in OGSA. In particular CDL may not be going to the full extent of supporting costing, etc., that maybe needed to address all requirements - Resources beneath the cut point can be considered as pre-provisioned: they either exist or they don't. They are not going to be deployed themselves; but they can be used to deploy on. - Which resource to choose for deployment? It is the choice of the EMS architecture (EPS, CSG) and not of CDDLM. - Discussion on how CDL may be viewed as a hierarchy of scripts; and that one could have a history of costs associated with each node. In other words the tree could be decorated with other information (cost, etc, as metadata) - JSDL and CDL relation and can one cover the requirements for the other - A JSDL submission may be associated with a deployment description or request, and the deployment portion could be described in CDL. [I.e., CDL could be a more specific application sub-type in a JSDL document.] - JSDL is not intended to describe the configuration of the software that will be used by the job. The aim is to describe things at a higher level. There may be similarities between the languages (perhaps around resource description) but it does not mean that one language can, or should, replace the other because they serve different purposes. - Jay wants to pursue the issue further among a smaller group of people. Actions: - Hiro to arrange the next joint call - Tentatively scheduled for Dec'21 due to various conflicts. - Dejan to arrange for a subteam call to discuss in more detail the provisioning/deployment issues, JSDL, CDL, etc. - Volunteers (mainly in Boston area or same timezone): Jay, Andrew, Stuart, Michael. * Naming Policy discussion Tom sent out the naming policy proposal to the list before the call. Briefly it states that OGSA fellow WG specifications must return EPRs. The EPRs may be decorated with more information but there should be no normative statement in the specifications that that information must be present. One technical issue is the level of coordination required for mandating WS-Names. The main point being the difficulty of quaranteeing uniqueness-in-space-and-time. For the uniqueness statement to be true an algorithm to create a unique string must be specified and everyone must agree to use it, which introduces a new set of problems. It was re-stated that the motivation for WS-Names is so that clients do not have to re-invent this kind of functionality. And that (for certain applications) this is really useful functionality. Andrew also read out portions of an email from Marvin Theimer on the need for WS-Names. (Andrew may send out the email to the list with Marvin's permission.) It was pointed out that there are two issues that should be discussed separately: - Reference resiliency; and - Equivalence checking And that Marvin's email calls out the need for resiliency rather than equivalence. In summary the technical issues are: 1. How to make sure that the identifiers (AbstractName) are unique 2. Some people might choose to provide resiliency using different mechanisms; and mandating this particular mechanism (unique identifier) forces implementations to create identifiers that the client software may not require or use. It was clarified that if a specification defines that EPRs are returned it does not stop a particular service implementation from decorating its EPRs with identifiers and therefore returning WS-Names. And that a mechanism to introspect services and determine whether they are in fact returning WS-Names could be provided. And that clients that absolutely require WS-Names could discover appropriate services that way. - For example, some (OGSA) profile might define a claim URI that means that compliant services return EPRs that are in fact WS-Names. Tom also explained that current tooling does not support extended types of EPRs. So defining an extension of EPRs such as WS-Names will *not work* with available tooling. This means that the WSDL defined by a specification such as BES would will still have to be defined as returning an EPR; and it is only some text in the specification that may make extra statements anyway. [So one cannot programmatically discover this feature.] Action: The next step is up to the BES-WG co-chairs: - Discuss this issue on a BES call and decide how to proceed. Options include the BES specification being redefined to return a URI and then also defining an optional porttype to 'resolve' that URI and so on.... Frank also raised the separate issue of whether the current formulation of WS-Naming is adequate. - There is a need to bind policy using unique identifiers. The current formulation of WS-Naming does not provide sufficient support because the unique identifier does not flow on the wire. - For this identifier to be useful for this purpose it must be part of the header of messages on the wire - Currently the AbstractName is defined as metadata so it does not get on the wire - Frank's proposal is to use the wsa:address IRI as the unique identifier - He has proposed this in the past but did not get an adequate response. He will raise it again on the list. Discussion to continue on the list. * Postponed for the future calls ** Common UML tool discussion - Michael to send out his evaluation in advance ** OGSA volunteer to give presentation in Israel ** Information model discussion - Postponed for next week. - It is pending on Andrew to provide the information that Ellen has asked for. * Next week - Agreed that despite SC'05 there should be sufficient people participating so the calls can go ahead as planned. - Monday call - Basic security profile (Takuya to send out final draft) - UML tool review - OGSA representative to Israel - The OGSA-AuthZ discussion should be re-scheduled for November 21 since it is not clear if members of AuthZ can participate (due to SC'05).