August 2012 - occi-wg - lists.ogf.org

Dasein Cloud
by Thijs Metsch 23 Jun '13

23 Jun '13

Hi, Just to inform you that there is a cool project going on called Dasein-Cloud. http://dasein-cloud.sourceforge.net/ On the website it reads: Dasein Cloud is an Open Source Java API made available by enStratus Networks LLC under the terms of the Apache License 2.0. This API specifies cloud-independent interfaces for enabling an application to access resources across multiple clouds. If you are interested have a look - and it might be great to implement OCCI in their someday! Cheers, -Thijs -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax

3 2

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

Message Queue on OCCI
by Srba, Maik 30 Aug '12

30 Aug '12

Dear all, we currently think about expanding OCCI so it supports a message queue between client and service provider. Our project contains simulation services in the cloud. For this we need a communication between client and simulation services. In one case it will be used to transmit control commands and receive status changes. Inside our project, we use RabbitMQ for messaging between client and simulation services, and among the different simulation service components. If this message queue would be part of an OCCI implementation, we could realize our management tasks for cloud simulation services via OCCI. It would be very nice to hear if somebody has already thought about this or could help collect ideas on how such an OCCI Extension could look like. Cheers, Maik ================================================================== GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 WWW: www.gwdg.de ------------------------------------------------------------------ Fon: 0551 39-20364 Fax: 0551 201-2150 AG (e)Science E-Mail: maik.srba(a)gwdg.de

5 12

Re: [occi-wg] CIMI specs approved
by Sill, Alan 29 Aug '12

29 Aug '12

Here is a link to the press release: http://dmtf.org/news/pr/2012/8/dmtf-releases-specification-simplifying-clou… Actual specs should be on the DMTF web site soon, if they are not there already. I'll see if there are other links or material that are released that we can share. Alan On Aug 29, 2012, at 10:09 AM, Alan Sill <alan.sill(a)ttu.edu> wrote: > No, but I'll try to get you a link to the public info and slides. > > I imagine implementation details might be pretty sensitive. They are, after all, a bunch of commercial competitors… > > Alan > > On Aug 29, 2012, at 9:40 AM, "Edmonds Andrew (edmo)" <edmo(a)zhaw.ch> > wrote: > >> Do you know with what implementations will be announced along side? >> >> >> >> On 29 Aug 2012, at 16:11, "Sill, Alan" <alan.sill(a)ttu.edu> wrote: >> >>> Version 1.0 of the CIMI specs have apparently been approved by the DMTF board. There will be a press release later today. >>> >>> Alan >

1 0

Reminder: conference call in 1h
by Metsch, ThijsX 28 Aug '12

28 Aug '12

Just a quick reminder...topic will be 'JSON' 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.

1 0

rOCCI-server 0.5 has just been released
by Feldhaus, Florian 24 Aug '12

24 Aug '12

With the help of Boris Parak we ironed out some remaining bugs in rOCCI-server and just released version 0.5. Download from https://github.com/gwdg/rOCCI-server/downloads The important changes are: * improved documentation * lots of bug fixes * preliminary JSON support * outsorced general OCCI functionality into occi gem * support for X.509 authentication * support for OS and resource templates in OpenNebula backend * new backend manager to support additional backends For the next version we plan to * further improve the OpenNebula backend * add stable VNC support * add EC2 support * improve scalability Please spread the word or retweet https://twitter.com/r_OCCI/status/238604868896563201 Cheers, Florian

2 1

NIST SAJACC interest group meeting and restart Tuesday, Aug. 21, 2:00-2:30 pm EST
by Sill, Alan 20 Aug '12

20 Aug '12

Dear NIST SAJACC working group, After much discussion with many interested parties, and some delays due to trying to get all of the support infrastructures in place for continued activity, I would like to propose to the group to restart some of the activities of the SAJACC group in use case definition and testing, with the goal of moving these activities beyond their initial atomic-level testing to include expanded and broader use case testing. NIST SAJACC interest group meeting Tuesday, Aug. 21 2012, 2:00-2:30 pm EST Join by Phone +1 (855) 834-4888 - Toll-free Conference ID: 34801340 The URL for the web conference tool for the meeting is: http://webconf.soaphub.org/conf/room/sajacc In proposing this, I am aware especially of the presence of new resources and projects that will enable us to test cloud use cases at a higher level, and with more emphasis on broader-scale interoperability and standards testing. In particular, here are a few examples. It should also be said that this restart effort has the approval and support of NIST people involved in the previous effort, and that we will make every effort to continue the previous good organizational and participation guidelines and principles. -- The IEEE has a new inter-cloud testbed that is being created to support the p2301 and p2302 efforts. -- OGF, ETSI and SNIA are cooperating on the new "Cloud Plugfest" series (http://cloudplugfest.org) which is on its 6th event iteration and continues with ETSI providing formal testing tools and logistical support to the ongoing testing series. -- The National Science Foundation supports the FutureGrid project,which is led by Indiana University with several US universities and large-scale computing centers (University of Chicago, University of Florida, San Diego Supercomputing Center, Texas Advanced Computing Center, University of Virginia,University of Tennessee, University of Southern California, Dresden, Purdue University, and Grid 5000) as partner sites. In this context we have proposed and had approved a Cloud Interoperability Testbed project, which is open for all interested parties to join. (https://portal.futuregrid.org/projects/176) -- The National Science Foundation has also funded an industry-supported Center for Cloud and Autonomic Computing (CAC), led by the University of Florida and with current sites at the University of Arizona; Rutgers, the State University of New Jersey and Mississippi State University and with site memberships under consideration at three other universities (Texas Tech University, the Univ. of Chicago and Indiana U.) with approval currently pending. (http://nsfcac.org) We intend to support the ongoing activities for SAJACC under the umbrella of the CAC if these projects are approved. Beyond this, there are interoperability efforts going on in several standards organizations, including the ITU-T, ISO, DMTF, OGF, ETSI, SNIA and related organizations such as the Cloud Standards Customer Council, Cloud Security Alliance, etc. that would merit our attention. I believe that it would be an ongoing service to the community to leverage the above activities in a way similar to the previous SAJACC efforts in order to define, describe, conduct (where possible), communicate, disseminate and document cloud interoperability efforts where they are relevant to the NIST cloud computing standards project mission. To do this, I would like to propose that we schedule an interest meeting to take place in the usual (though not recently used!) SAJACC meeting time of 2:00 pm Tuesday, Aug 21, with the goal of starting monthly or bi-weekly meetings of the full SAJACC group thereafter. To register for access to the NIST SAJACC working group TWiki and e-mail list, if you are new to this effort, please see the information and fill out the sign-up form by checking the "SAJACC" box at http://www.nist.gov/itl/cloud/workinggroups.cfm Other information: the NIST Cloud Computing web site is http://www.nist.gov/itl/cloud/ The SAJACC group information page is http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/S… Further information on testing tools and access to related cooperating projects as discussed above will be given at the organizational interest meeting. If you have an interest in presenting any information at the meeting, please let me know. If you have any questions, please feel free to contact me using the details below. I look forward to any and all input on this important topic. Please distribute this message as appropriate to any other interested parties, and I look forward to our conversation during the SAJACC meeting next Tuesday, Aug. 21, 2:00-2:30 pm EST. Alan Alan Sill, Ph.D Vice President of Standards, Open Grid Forum Senior Scientist, High Performance Computing Center Adjunct Professor of Physics, TTU ==================================================================== : Alan Sill, Texas Tech University Office: Drane 162, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-834-5940 fax 806-834-4358 : ====================================================================

1 1

References in OCCI schema (JSON) and W3C Linked Data
by Gary Mazz 14 Aug '12

14 Aug '12

Hi, Sorry this took so long, the day job and family stuff is taking up time. I took a deeper dive into W3C Linked Data as input to reconciling References for the JSON specification.Linked Data is a mechanism to create a "web of data". Under the W3C, Linked Data is identified and addressed though HTTP URIs. Currently, the W3C has Linked Data defined in several specifications including RDF, RDFa, GRDDL, POWDER, Semantic Annotation and Provenance. Many of W3C work products are implemented using XML data representations. In some cases, identified OCCI and external Resources will not always be addressable by HTTP. In some environments, URIs are required to be defined as non-HTTP URLs. Service Location Protocol RFC2808, commonly used by iSCSI servers, is one such case. iSCSI is another case. The OCCI Core document defines an 'id' attribute for all Entity objects (Resources and Links) as a URI. No reference to HTTP is included with the URI definition. In this case, URI is intended to be media agnostic. In OCCI's HTTP specification, OCCI URIs are defined as HTTP URI with no recognizable support for alternate media identifiers ie iSCSI. One position on this practice is that Alternate Identifiers could be considered implicitly defined in the rendering specification of an OCCI Reference. However, a more pragmatic commentary of this practice would consider Alternate Identifiers as undefined strings. A best practice could consider the Mixin as a vehicle to specify URI media type. This email does not draw conclusions of make any significant recommendations. It has the sole purpose to identify issues surrounding Refernces and links for JSON rendering specification. Discussion is the obvious next step towards reconciliation. cheers, gary

2 1

Reminder: confcall in 1h
by Metsch, ThijsX 14 Aug '12

14 Aug '12

Hi all, Florian will be leading todays call - Dial in details: 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.

1 0

Attribute descriptions
by Gary Mazz 07 Aug '12

07 Aug '12

Hi, Sorry this took so long, had a family medical emergency which took up most of last half of week and the weekend. There is one or two items about attributes that I believe needed to be clarified. As well as one or two items that are potential for conflicts. I listed them below, they will warrant a discuss and vote to see which capability we would consider supporting. 1) I believe we need a definition for attributes in the document... The definition needs to qualify the role of attributes and properties of the attributes. 2) Differentiate between OCCI Resource attributes and Attributes defined by Mixins. 3) Mixins may reference attributes defined in external schemas, DMTF's CIM for example. We need a way to filter attributes sourced from external schemas and hopefully not overload OCCI clients, servers or other information management vehicles (ie templates). This capability may also be required for the converse case, identifying attributes that will be used, all other will be ignored. This use case may also valid for OCCI Resource defined attributes. 4) The OCCI server should have the ability to override attributes defined in external schemas and OCCI Resources. The overridden attributes warrants a discrete definition, not to confuse externally defined attributes with server defined attributes. These attributes may fall into the class of "calculated attributes". 5) Indicators: An Indicator is threshold based logic used to show whether a metric is operating within a set of limits. Indicators may be polled by the client using traditional client/server technologies or pushed to the client by the server through asynchronous methods. What an indicator looks like is interesting.. we need to determine the following: a) Do Indicators contain more then one threshold? b) Can Indicators send or trigger asynchronous events, if yes, what does it look like ? c) Should each Indicator have a name ? c) How is MetricName/Indicator naming schema defined ? What does the canonical form look like ? cheers, gary

4 4