Dear Igor, I agree, regarding the entire SLA life-cycle is certainly a relevant and interesting topic. However, beyond the scope of the GRAAP working group. I would support starting a new group with an appropriate charter as soon as we finish the experience document and have re-chartered the GRAAP-wg for the final work on multi-round negotiations of SLAa based on WS-Agreement. To that extent, I think that 3 and 6 will be completely addressed by WS-Agreement. Also 1 will be addressed in WS-Agreement since creation of templates is an issue when looking on interoperability. For the other points I agree with Heiko that we probably won't need a standard there. But this could be clarified during the discussion when preparing a BoF for a new wg ;-) Best regards Wolfgang Heiko Ludwig schrieb/wrote:
Revisiting the life cycle is certainly a good idea to decide on next steps.
My take is that 2 has been addressed by WS-Agreement, even though maybe not to the full extent required to drive the subsequent negotiation phase if more sophisticated protocols are to be required. Generally, as Igor is pointing out, it provides some content structure underpinnings that can be used throughout the life-cycle.
The next question we should ask ourselves is what parts of this life-cycle should be standardized and where competing approaches provide more benefits for tools and services providers and customers. Is anyone aware of a good metric for this decision process?
Heiko
----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center based at Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099 hludwig@us.ibm.com, tel. +1 408-927-1488, mob. +1 646-675-8469 http://www.research.ibm.com/people/h/hludwig/
Inactive hide details for "Igor Rosenberg" ---03/02/2009 07:05:31 AM---Hello, I'd like to get in more detail of the "standardis"Igor Rosenberg" ---03/02/2009 07:05:31 AM---Hello, I'd like to get in more detail of the "standardisation of SLA
From: "Igor Rosenberg" <igor.rosenberg@atosresearch.eu>
To: <graap-wg@ogf.org>
Date: 03/02/09 07:05 AM
Subject: [GRAAP-WG] OGF: SLA framework
------------------------------------------------------------------------
Hello, I'd like to get in more detail of the "standardisation of SLA frameworks" idea I'd mentioned last month. Within the GRAAP group, a (pre)standard has been defined on how an SLA should look like, and how to create it. Fine. But this is only a fraction of what is needed for an implementation of SLAs for business. Let me present a possible view of the SLA lifecycle:
A- Contract definition phase 1. Template creation 2. Publication&Discovery B- Negotiation phase 3. Negotiation 4. Optimisation of resources C- Enforcement Phase 5. Monitoring&Evaluation 6. Re-Negotiation 7. Accounting D- De-Commisioning phase 8. De-Commisioning
Within GRAAP, only point 3 has really been addressed. If we look at other SLA "standards", like the ones presented in GRIA, GRASP, etc., we can see a lot of research effort in lots of SLA concepts. I personally think it is time to present some rationalized views of the previous work which has been done, and try to fix into a standard the basic blocks of an SLA framework. A possible starting point is [1] below. What functionality is required to have a framework which supports SLAs? Which are the optional bits, what do they add? GRIA and GRASP have a working SLA framework, how much work is needed to bring WS-Agreement to this level? I have a keen interest in seeing how an enforced agreement should be treated, both by provider and client: how do guarantees get evaluated fairly, how much information should the client receive, is it fair to let the provider request a re-negotiation, who sorts out litigations, etc.
Or am I trying to go too fast? Do we need to see more implementations of WS-Agreement (negotiation) before trying to expand?
Well, any comments appreciated...
Regards Igor Rosenberg, Research Engineer, Atos Origin, Spain
[1] A Comparison of SLA Use in Six of the European Commissions FP6 Projects, M. Parkin, R. M. Badia, J Martrat
http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0129.pd f
-----Original Message----- From: Philipp Wieder [mailto:philipp.wieder@udo.edu] Sent: lunes, 23 de febrero de 2009 14:19 To: Igor Rosenberg Cc: graap-wg@ogf.org Subject: Re: [GRAAP-WG] OGF: SLA framework
Hi Igor,
thanks for the contribution.
A first easy step to inform the community is to add your implementation to the respective site at the WS-Agreement web [1]. Just send me a link and two sentences and I will add it there.
Secondly, it would be good to get your feedback on your actual implementation of WS-Agreement for the experience document. We have a questionnaire [2] for that an it would be very helpful for GRAAP if you filled it.
Regarding the standardisation of SLA frameworks I am not sure what you are referring to in detail. Could you please elaborate a bit more on this and we than can decide whether this is within the scope of GRAAP.
Best regards, Philipp.
[1] https://forge.gridforum.org/sf/wiki/do/viewPage/projects.graap-wg/wiki/I mplementations [2] https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.graap -wg/docman.root.current_drafts.ws_agreement_experience_docuemnt/doc15358
Hello GRAAP group, Within the EU BeinGrid project (beingrid.eu), we've been developing an SLA framework for GT4. It is based on a component architecture (by
understand independent modules). I have some material that describes it that I could pass to the community, including a paper (attached). Implementation of the different components is finished (nearly all components are licensed as Apache V2, only one is freeware binary), and we're currently making sure it all integrates smoothly. I think it should be advertised to the OGF community (at least the guys and girls interested in GT4). I also propose that from the work done, we could
to standardize the SLA frameworks that exist for Grids (GRIA, GRASP, Unicore, and now GT4); btw our framework is based on the March 2007 WS-Agreement specification of the OGF, which describes SLA contracts (www.ogf.org/documents/GFD.107.pdf), but is meant to be generic (different SLA formats can be plugged in) . What would be the way forward? Who should I get in touch with? Regards
Igor Rosenberg, Research Engineer, Atos Origin, Spain ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus
Igor Rosenberg wrote: this, try transmitted.
Este mensaje y los ficheros adjuntos pueden contener informacion
confidencial
destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------
------------------------------------------------------------------------
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
------------------------------------------------------------------------
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 SmartLM - Software Licence Technology for Grids, Clouds, SOA: www.smartlm.eu CoreGRID Network of Excellence www.coregrid.net Institute on Resource Management and Scheduling www.coregrid.net/irms