- occi-wg - lists.ogf.org

Re: [occi-wg] [nsmwg] Groups - TR_178_V2012-0921_V0-3.docx uploaded
by Augusto Ciuffoletti 15 Oct '12

15 Oct '12

Alex, as you know, inside the OGF working group OCCI (stands for Open Cloud Computing Interface) we are trying to define the guidelines for SLA in clouds. With this aim I tried to modularize the complex issue of SLA as-a-whole into a few sub-problems. Per se the SLA topic extends from the definition of legal details to performance measurement: definitely too much for a single document that wants to give precise guidelines. So I started by extracting the resource monitoring sub-problem. Such functionality is present in many aspects of distributed computing, and exhibits a sufficiently simple (and sufficiently understood) interface with other components. In our perspective the specification of the monitoring infrastructure does not include neither the indication of relevant metrics, nor the technology used to retrieve them: we focus on the arrangement of sensors attached to resources, that may accept as "plugins" specific measurement tools, as well as measurement aggregators and publishing supports. In DMTF IS0102 there are sparse references to such a monitoring infrastructure, and its role is explicitly addressed (for instance in section 7.8). While reading your document "TR178 Enabling e2e Cloud SLA Management" the topic is covered in better detail. While defining the tightly related topic of metrics (in sect. 3.4 of version 0.3), you notice the importance of defining how metrics are used, and on the existence of a reliable infrastructure for resource monitoring that ensures comparable results. In section 4.3 you state that a *well defined service* must give the consumer some access to monitoring facilities, with an interface mediated from a TM Forum document. The interest for an agreed definition of the monitoring infrastructure is implicit in a number of *future work recommendations* in your document (sect. 6): Recommendation 4 asks the inclusion of the description of the *container of service metrics* as a part of the Service Template, Recommendation 6 indicates the definition of metrics as a continuous effort, and thus mandates a flexible infrastructure for their management. This given, I consider you are probably interested in the working draft about the resource monitoring infrastructure I have recently proposed to the OGF-OCCI working group. The purpose of the document, in the spirit of OCCI, is to define an interface to the resource monitoring infrastructure. The interface follows a restful approach, and gives the way to create, configure and discover resource monitoring entities. I hope that the ideas contained in the document are helpful for your task, and I will be pleased to receive any comment about the document (that you find in attachment) from your community. Faithfully, Augusto 2012/10/11 Alex Zhdankin <azhdanki(a)cisco.com> > *Submitter's message* > Colleagues, > > This document was jointly developed and submitted by TM Forum for comments > and further input. Please, review this Technical report and provide any > comments you may have. The topic of SLA management in Cloud environment is > directly related to the work we are doing in several groups, including > CMWG, NSMWG and SVPC, so, please take a look and comment. > > Thank you and Regards, > > Alex. > > -- Mr. Alex Zhdankin *Document Name*: TR_178_V2012-0921_V0-3.docx<http://members.dmtf.org/apps/org/workgroup/nsmwg/document.php?document_id=6…> > ------------------------------ > *Description* > This document adresses the issues of End-to-End SLA management in the Cloud > ecosystem. The goal of this Technical Report is to enable people in > different communities to develop Cloud SLAs and SLA metrics such that > associated systems can be joined to facilitate end-to-end SLA management of > a single cloud or multi-cloud environment. This Technical Report (TR178), > while organized by the TM Forum, takes an outside-in look by reviewing > existing relevant industry work (DMTF, OGF, NIST, ITU-T, ISMA, OASIS and > other), as well as the TM Forum Frameworx, SLA management Handbook and > Cloud SLA Application Notes. It then recommends a set of business > considerations and architecture design principles that are required to > support end-to-end Cloud SLA Management with the aim to facilitate > discussion regarding SLA consistency across Cloud Deployment Models and > Services Models. > Download Latest Revision<http://members.dmtf.org/apps/org/workgroup/nsmwg/download.php/68634/latest/…> > ------------------------------ > *Submitter*: Mr. Alex Zhdankin > *Group*: Network Services Management Working Group > *Folder*: TMF alliance > *Date submitted*: 2012-10-11 06:10:37 > > -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

1 0

End-to-End SLA management in the Cloud
by Feldhaus, Florian 11 Oct '12

11 Oct '12

See mail below for some interesting news regarding SLAs. As the document is password protected and I'm not sure that I'm allowed to share it over a mailinglist, please contact me if you want to read the document and if you're not a member of DMTF. Cheers, Florian Anfang der weitergeleiteten E-Mail: > Umgeleitet von: <florian.feldhaus(a)tu-dortmund.de> > Von: <azhdanki(a)cisco.com> > Betreff: [nsmwg] Groups - TR_178_V2012-0921_V0-3.docx uploaded > Datum: 11. Oktober 2012 15:10:43 MESZ > An: Undisclosed recipients:; > > Submitter's message > Colleagues, > > This document was jointly developed and submitted by TM Forum for comments and further input. Please, review this Technical report and provide any comments you may have. The topic of SLA management in Cloud environment is directly related to the work we are doing in several groups, including CMWG, NSMWG and SVPC, so, please take a look and comment. > > Thank you and Regards, > > Alex. > > -- Mr. Alex Zhdankin > Document Name: TR_178_V2012-0921_V0-3.docx > Description > This document adresses the issues of End-to-End SLA management in the Cloud > ecosystem. The goal of this Technical Report is to enable people in > different communities to develop Cloud SLAs and SLA metrics such that > associated systems can be joined to facilitate end-to-end SLA management of > a single cloud or multi-cloud environment. This Technical Report (TR178), > while organized by the TM Forum, takes an outside-in look by reviewing > existing relevant industry work (DMTF, OGF, NIST, ITU-T, ISMA, OASIS and > other), as well as the TM Forum Frameworx, SLA management Handbook and > Cloud SLA Application Notes. It then recommends a set of business > considerations and architecture design principles that are required to > support end-to-end Cloud SLA Management with the aim to facilitate > discussion regarding SLA consistency across Cloud Deployment Models and > Services Models. > Download Latest Revision > Submitter: Mr. Alex Zhdankin > Group: Network Services Management Working Group > Folder: TMF alliance > Date submitted: 2012-10-11 06:10:37 >

2 1

Re: [occi-wg] Info about OCCI Java client libraries
by Brian Amedro 09 Oct '12

09 Oct '12

Hello Florian, Really nice to hear from you :) We are working hard on the "jOCCI" library, which is available on : http://gitorious.ow2.org/ow2-proactive/jocci - Now we can load a model with a json representation - for each model, an HTTP Server can receive requests (at the moment, HEAD and GET for discovery) Any feedback would be greatly appreciated, Cheers, Brian On Sat, Oct 6, 2012 at 9:27 PM, Feldhaus, Florian <florian.feldhaus(a)gwdg.de> wrote: > Hi everyone, > > during the Cloud Plugfest we had a discussion on the development of a OCCI Java library. Brian Amedro and his colleagues are developing a new Java library. It would be great if you could share your ideas and your code so that we get a good, usable OCCI Java library. > > Cheers, > Florian > > Am 04.10.2012 um 11:22 schrieb Metsch, ThijsX: > >> Sure - in case it hasn't been done already :-) >> >> Michael: please meet Alessio who is interested in an Java OCCI client. >> >> Alessio: Michael is one of the contributors to the OCCI working group and did some great work on mobile clients for OCCI and CDMI! >> >> Cheers, >> >> -Thijs >> >> -----Original Message----- >> From: Edmonds Andrew (edmo) [mailto:edmo@zhaw.ch] >> Sent: Thursday, October 04, 2012 11:19 AM >> To: Metsch, ThijsX >> Cc: Edmonds Andrew (edmo); Tassilo Galonska; Alessio Graziani >> Subject: Re: Info about OCCI Java client libraries >> >> Thijs, could you make the necessary intros? >> >> On 4 Oct 2012, at 11:17, "Metsch, ThijsX" <thijsx.metsch(a)intel.com> wrote: >> >>> Not yet - we figured out that R2ND might be able to help on the confcall on Tuesday. >>> >>> Cheers, >>> >>> -Thijs >>> >>> -----Original Message----- >>> From: Edmonds Andrew (edmo) [mailto:edmo@zhaw.ch] >>> Sent: Thursday, October 04, 2012 11:17 AM >>> To: Tassilo Galonska >>> Cc: Edmonds Andrew (edmo); Alessio Graziani; Metsch, ThijsX >>> Subject: Re: Info about OCCI Java client libraries >>> >>> Perhaps tuOCCI has a java model that can be reused? If it was so then there'd be some time saved. >>> >>> Thijs any idea about the jclouds work? >>> >>> On 2 Oct 2012, at 17:45, "Tassilo Galonska" <tassilo.galonska(a)tu-dortmund.de> wrote: >>> >>>>> Now I have a question: the occi4java tuOCCI libraries are used server side to add to a Cloud server the OCCI interface, or can also be used client side to connect to a Cloud server by using OCCI? >>>> >>>> tuOCCI does not provide an OCCI client. I am pretty sure that >>>> occi4java does not provide one as well. >>>> >>> ------------------------------------------------------------- >>> Intel Ireland Limited (Branch) >>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland >>> Registered Number: E902934 >>> >>> This e-mail and any attachments may contain confidential material for >>> the sole use of the intended recipient(s). Any review or distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >>> >> ------------------------------------------------------------- >> Intel Ireland Limited (Branch) >> Collinstown Industrial Park, Leixlip, County Kildare, Ireland >> Registered Number: E902934 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >

4 7

Re: [occi-wg] About OCCI in Cloud Plugfest this December
by Silvia Almagia 09 Oct '12

09 Oct '12

Dear Jazz, Yes, there will certainly be some OCCI implementations attending the December cloudplugfest. And yes, one of the event hosts will be ETSI in Sophia Antipolis, France. There might be some additional hosts for December's event, this will be announced in the following days with the call for participation. Hope this helps, just let me know if you need any further information, Best regards, Silvia, on behalf of the CloudPlugfest planning team ------------------------------------------------------------------- Silvia ALMAGIA Technical Expert Centre for Testing and Interoperability (CTI) European Telecommunication Standards Institute (ETSI) Tel: +33 (0)4 92 94 49 64 Mob: +33 (0)6 69 70 68 86 www.etsi.org  Please consider the environmental impact before printing this e-mail -----Original Message----- From: Jazz Yao-Tsung Wang [mailto:jazz@nchc.narl.org.tw] Sent: 09 October 2012 12:05 To: info(a)cloudplugfest.org; occi-wg(a)ogf.org wg Subject: About OCCI in Cloud Plugfest this December Dear all, Will there be any session about OCCI in Cloud Plugfest this December? Will it be hosted at ETSI - Einstein Building ? http://www.cloudplugfest.org/next-event/plugfest-agenda http://www.cloudplugfest.org/next-event/location-details We're new to OCCI working group but like to join the discussion of new OCCI standard. Regards, Jazz Yao-Tsung Wang Associate Researcher Natioanl Center for High-performance Computing NARL, Taiwan

1 0

Re: [occi-wg] Info about OCCI Java client libraries
by Michael Behrens 07 Oct '12

07 Oct '12

We'd be happy to help as needed. For those that do not already know, our code for our clients is on github: https://github.com/r2ad It would be good to refactor and come up with a common OCCI model. Then add some libraries for access, getting resources, updating resources, status checking of resource creation (asynchronously), parsing, etc. Feldhaus, Florian wrote: > Hi everyone, > > during the Cloud Plugfest we had a discussion on the development of a OCCI Java library. Brian Amedro and his colleagues are developing a new Java library. It would be great if you could share your ideas and your code so that we get a good, usable OCCI Java library. > > Cheers, > Florian > > Am 04.10.2012 um 11:22 schrieb Metsch, ThijsX: > >> Sure - in case it hasn't been done already :-) >> >> Michael: please meet Alessio who is interested in an Java OCCI client. >> >> Alessio: Michael is one of the contributors to the OCCI working group and did some great work on mobile clients for OCCI and CDMI! >> >> Cheers, >> >> -Thijs >> >> -----Original Message----- >> From: Edmonds Andrew (edmo) [mailto:edmo@zhaw.ch] >> Sent: Thursday, October 04, 2012 11:19 AM >> To: Metsch, ThijsX >> Cc: Edmonds Andrew (edmo); Tassilo Galonska; Alessio Graziani >> Subject: Re: Info about OCCI Java client libraries >> >> Thijs, could you make the necessary intros? >> >> On 4 Oct 2012, at 11:17, "Metsch, ThijsX" <thijsx.metsch(a)intel.com> wrote: >> >>> Not yet - we figured out that R2ND might be able to help on the confcall on Tuesday. >>> >>> Cheers, >>> >>> -Thijs >>> >>> -----Original Message----- >>> From: Edmonds Andrew (edmo) [mailto:edmo@zhaw.ch] >>> Sent: Thursday, October 04, 2012 11:17 AM >>> To: Tassilo Galonska >>> Cc: Edmonds Andrew (edmo); Alessio Graziani; Metsch, ThijsX >>> Subject: Re: Info about OCCI Java client libraries >>> >>> Perhaps tuOCCI has a java model that can be reused? If it was so then there'd be some time saved. >>> >>> Thijs any idea about the jclouds work? >>> >>> On 2 Oct 2012, at 17:45, "Tassilo Galonska" <tassilo.galonska(a)tu-dortmund.de> wrote: >>> >>>>> Now I have a question: the occi4java tuOCCI libraries are used server side to add to a Cloud server the OCCI interface, or can also be used client side to connect to a Cloud server by using OCCI? >>>> tuOCCI does not provide an OCCI client. I am pretty sure that >>>> occi4java does not provide one as well. >>>> >>> ------------------------------------------------------------- >>> Intel Ireland Limited (Branch) >>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland >>> Registered Number: E902934 >>> >>> This e-mail and any attachments may contain confidential material for >>> the sole use of the intended recipient(s). Any review or distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >>> >> ------------------------------------------------------------- >> Intel Ireland Limited (Branch) >> Collinstown Industrial Park, Leixlip, County Kildare, Ireland >> Registered Number: E902934 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >>

1 0

Inline Link creation with JSON
by Ralf Nyren 02 Oct '12

02 Oct '12

Hi, The question was raised during today's confcall how to create an OCCI Link bound to an OCCI Resource at creation time. Example: POST /compute/ HTTP/1.0 { "resources": [ { "kind": "http://schemas.ogf.org/occi/infrastructure#compute", "attributes": { "occi": { "compute": { "speed": 2.33 } } } } ], "links": [ { "kind": "http://schemas.ogf.org/occi/infrastructure#networkinterface", "attributes": { "occi": { "networkinterface": { "interface": "eth0", "mac": "00:80:41:af:12:fd" } } }, "target": "/network/bc8516d0-0cc3-11e2-b9e9-6f750173de61", } ] } This would create a new Compute instance with a (new) NetworkInterface Link to an existing Network instance. When a single resource instance is specified in "resources" it is assumed to be the "source" of every Link in "links". regards, Ralf PS. Florian, please feel free to correct this if I got something wrong. DS.

1 0

OCCI JSON data format
by Feldhaus, Florian 02 Oct '12

02 Oct '12

After the discussion in the OCCI ConfCall Ralf and I went through the JSON document and identified open issues and how we would solve them. The result is attached as pdf and committed to the new JSON branch in the OCCI WG Git. Following is a short explanation of the design goals: * the overall design goal was to create a data format which is independent from the transport protocol * also important was a compact representation of all OCCI Entities as they may be exchanged very often * OCCI Categories could be verbose to describe the Model in detail * information should be easily accessible Some explanations on specific sections: 4.1 - for attributes the dot notation should be used and each namespace should be rendered as a separate object. This follows best practice in JavaScript to handle nested attributes and should help adoption. 4.2 - type identifiers as used for 'kind', 'mixins' and 'action_categories' are pointers to other objects within the OCCI Core scope and thus are rendered in the top level object. 4.2 - id is rendered in the top level object. The reason is, that id is a pointer to the object itself, thus it is not an attribute, but a OCCI Core property of the object itself comparable to 'self' in many programming languages. Besides it is difficult to specify rules on how id must be rendered if it is not in the top level object. 4.2 - links are represented by the URN of their id following RFC 4122. This is a more compact representation of the link as we had it before. Also it resembles the behavior of id. Thus it is rendered in the top level object 4.3 - source and target are also pointers to objects within the OCCI Core object scope. Thus they are rendered in the top level object. Similar to id it is difficult to specify rules on how source and target must be rendered if they are not within the top level object. 4.3 - the type identifier in 'rel' is a pointer to a OCCI Category and thus rendered in the top level object 4.4 - instantiated actions need to be represented in a format similar to that of OCCI Entities. Actions don't have an 'id' as they are only used once and are not persistent 4.5 - term, scheme, attributes, actions and related are OCCI Core properties of the 'kind' object and thus rendered in the top level scope 4.5 - location is transport protocol specific, but must be an URI. Each transport protocol must specify guidelines for location 4.7 - the action category format is used to define actions similar to kinds describing OCCI entities 4.8 - the attribute description format has been simplified. The general description of attributes went to 4.1. The attribute properties have been reduced to mutable, required, type, default and description. As Pattern complicated matters a lot it was removed. Cheers, Florian

3 5

Reminder: confcall today
by Metsch, ThijsX 02 Oct '12

02 Oct '12

Hi all, Important call today on JSON and the OCCI core document! Please join at 4pm UTC, 5pm GMT, 6pm CET. Numbers: Austria 0820 4000 1503 Belgium 070 35 99 45 Canada 1 213 289 3444 France 0821 230 748 Germany 01803 001 178 Ireland 0818 270 007 Italy 848 390 166 Netherlands 0870 001 909 Poland 0801 003 533 South Africa 087 550 0375 Spain 902 885 318 Sweden 0939 2066 400 Switzerland 0848 560 190 United Kingdom 0844 4 73 73 73 United States 1 415 363 0833 More: http://pdf.powwownow.com/pdf/USA_en_pwn-dial-in-numbers.pdf PIN code: 698133 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 3

Core errata
by Ralf Nyren 25 Sep '12

25 Sep '12

Dear all, I have update the Core document to include the changes discussed on the last few confcalls. The LaTeX changes are available from the core-errata branch in the occi-wg Git repository. Please find a compiled document attached. Add a Attribute type to the Core Model -------------------------------------- Many who have implemented the OCCI Core model already added an Attribute type. This change formalise the notion of "attribute properties". Instead of just saying an attribute have a name, an attribute now has its on Attribute type with both name an properties. The new Attribute type is an *identifier* for resource attributes. It does not contain the attribute value. I.e. just as before. A distinction has been added between "client discoverable attributes" (called OCCI Attributes) and attributes internal to the model (called model attributes). occi.core.id, occi.core.source and occi.core.target have been changed back to the model attributes they were until shortly before HTTP Rendering was released. These are determined to be model attributes and thus receive special care in renderings. Change Action to inherit Category --------------------------------- The concept of Action representing the "invocable operation" itself is removed. Instead an Action is just an *identifier* of the operation. An Action instance identifies an invocable operation in much the same way as a Kind instance identifies an Entity sub-type. Impact on the existing HTTP Rendering (occi/1.1) is none. In fact the text/ renderings already use "type=action" in its Category headers. regards, Ralf

5 11

OCCI F2F
by Edmonds Andrew (edmo) 25 Sep '12

25 Sep '12

Hi all, We have great experience with running dedicated OCCI workshops where various issues in the specification can be resolved quickly and easily. As not many can attend OGF36 or have calendaring conflicts, we would like to arrange one on November 13th (Tuesday) and host it in Zurich. Anyone is more than welcome to join so long as their willing to pull up their sleeves and get busy with specification work and related discussions. We will also arrange conference call facilities for those not able to attend. Further details to follow. Andy Andy Edmonds Senior Researcher Institute of Information Technology Zürich University of Applied Sciences http://www.cloudcomp.ch, @dizz

2 2