September 2013 - occi-wg

How to make two clouds communicate with each other using occi
by aok pan 28 Sep '13

28 Sep '13

Dear Sir , Please advice if you can help me with my task i have two open nebula clouds already installed and also OCCI servers on top of them i need to satisfy communication between the two clouds using the OCCI . Please advice. B.rgds Amira (Master Student at The AAST Egypt)

1 0

OCCI XML description
by Jean Parpaillon 26 Sep '13

26 Sep '13

Hi, Following the OCCI-WG session in Madrid and my presentation at the workshop, please find here the link to the work I've done on XML representation of OCCI. The presentation: http://fr.slideshare.net/JeanParpaillon/occi-xml-description The schemas and examples: https://github.com/jeanparpaillon/occi-schemas The objective is to be able to describe in a formal way the OCCI extensions, independantly from implementation languages (Python, Ruby, Java, etc). Basic architecture: - XSD describe OCCI types XML representation - OCCI extensions are described with XML files, validated with XSD. - OCCI representation can be validated with above XML file, which is not an XSD. Nervertheless, XML extension file is formal enough for implementation to validate rendering. For attribute types (string, numbers, etc.), we use the XML schema type model to describe them. For instance, a mac address is described with: <xs:simpleType name="mac802"> <xs:restriction base="xs:string"> <xs:pattern value="[\da-fA-F]{2}(\:[\da-fA-F]{2}){5}" /> </xs:restriction> </xs:simpleType> Your comments are welcome, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

3 4

Fwd: Re: XML for OCCI
by Jean Parpaillon 26 Sep '13

26 Sep '13

Sharing this discussion on XML rendering... -------- Message original -------- Sujet: Re: XML for OCCI Date : Tue, 24 Sep 2013 11:03:22 +0200 De : Augusto Ciuffoletti <augusto.ciuffoletti(a)gmail.com> Pour : Jean Parpaillon <jean.parpaillon(a)free.fr> You can certainly share with the group. I'm elaborating an answer, that I'll post to the group. 2013/9/24 Jean Parpaillon <jean.parpaillon(a)free.fr <mailto:jean.parpaillon@free.fr>> Hi Augusto, Le 24/09/2013 10:06, Augusto Ciuffoletti a écrit : > Jean, > > sorry for not being at your presentation: I concentrated on the OGF > session, and I did not consider other good reasons to participate. > No harm: I'm really interested in contributing to OCCI specifications and I have no doubt we have another occasion to meet ! On my side, I have seen your spec about monitoring I consider a really important topic but I am now more focusing on core and renderings parts. > I always started from the assumption that the "true" rendering was HTML, > which is definitely not a simplifying assumption. The JSON and XML > renderings open entirely new horizons. > > I submit you two problems I have with the monitoring API: > > -) one is subtyping mixins, binding their semantic (not simply their > syntax): this is done by introducing tagging mixins, and then saying > that a mixin related with a certain tag must have "certain" attributes > Mixin can also have their own attributes, isn't it enough ? Can you give me an example ? I must admit mixin is a concept I'm not really confortable with. I consider they should be use to add attributes to a resource when is does not make sense to have a separate id for it, but I may be wrong. > -) the other is describing such "certain" attributes: their value is > used to establish a relationship with complementary attributes in > another entity, which is the desired "semantic" (like a "port_number" > attribute) Ok, this is a problem not specific to mixins, IMO. Attributes typing in general should be more advanced in OCCI and, in particular, an attribute could be an OCCI type. My proposal does not handle yet this complex type, even if think it is necessary to handle it. As a quick draft of proposal, I think the following should work: <occi:kind term="manifest" scheme="http://example.org/myschemas#" > <occi:rel term="resource" scheme="http://schemas.ogf.org/occi/infrastructure#" /> <occi:attribute name="nodes" type="occi:entityAttr" minOccurs="0" maxOccurs="unbounded" > <occi:rel term="compute" scheme="http://schemas.ogf.org/infrastructure#" /> </occi:attribute> </occi:kind> .. my proposal is missing the definition of "entityAttr", which would be: <xs:complexType name="entityAttr" > <xs:sequence> <xs:element name="rel" type="occi:relatedType" /> </xs:sequence> </xs:complexType> We could then validate the following resource: <occi:resource id="...." > <occi:kind term="manifest" scheme="http://example.org/myschemas#" /> <occi:attribute name="nodes > <occi:value>/path/to/compute/resource</occi:value> <occi:value>/path/to/another/compute/resource</occi:value> </occi:attribute> </occi:resource> Of course, this would imply some code to implement it (it is not pure XSD), but the information is there. > > I see no way to introduce this in an xml schema, but I've never tried > to. In these days, I'm thinking to RDF. Any opinion about this? > I have never used RDF. Anyway, thank for the occasion to provide concrete example of complex attributes. Do you mind I forward this to occi-wg list for comments ? Best regards, Jean > > -- > Augusto Ciuffoletti > Via Milano 118 > 38122 - Trento -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 <tel:%2B33%206%2030%2010%2092%2086> im: jean.parpaillon(a)gmail.com <mailto:jean.parpaillon@gmail.com> skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en -- Augusto Ciuffoletti Via Milano 118 38122 - Trento

2 3

OCCI Core/Rendering feedback
by Jean Parpaillon 26 Sep '13

26 Sep '13

Hi, As proposed during our session in last plugfest, here is my feedback about OCCI Core (and rendering). Background: - while working on CompatibleOne project, try to propose an XML representation of OCCI - developing an erlang-based OCCI framework (erocci) Comments; == == Understandability == It took me a lot of time to understand the categorization meta-model. These comments are highly subjectives then... Nevertheless, I think the following items could help understand the specifications more quickly: - In a general way, OCCI Core specification could provide some more examples to understand the categorization model. HTTP and infrastructure specifications have been of greater help than Core. - OCCI Core specifications could clarify the link between OCCI types and notions most of developers are familiar with, like: objects, classes, interfaces, polymorphisms, etc. == == Missing == Some elements should be present in the OCCI Core specification for avoiding any ambiguity in the implementations. - attribute default value: when an attribute is required and immutable, it is up to the implementation to choose a default value when creating the resource. The specification should provide a default value in this case. - attribute base typing: the specification should formalize base types for attributes. XML schema specification provides 44 "builtin" types[0], for instance. - attribute type extension/restriction: in Infrastructure specification, for instance, extended types are used, but not formally defined: enum, ip, mac address, etc. The OCCI Core specification should provide some mechanisms to extend/restrict base types: enumeration, string patterns, decimal precision ?, integer range ?, etc. - state machine: many actions are defined with the target state of the resource. The OCCI specification may provide a way to define state-machine handling in a formal way. I've been working on the Aeolus project[1] which published really interesting model for planification of resources handling on cloud systems. I'm still in touch with them and they look interested in using OCCI to implement their system. This is quite mid term action but I will keep you informed if something interesting comes from that. == == Rendering specifications == All rendering specifications should include a formal grammar or schema. Andy Edmonds has provided a text/plain and text/occi rendering antlr grammar. Nevertheless, many of quoted values need to be parsed again to get the full structure of the request. I'm not aware enough of antlr to know if we can do better, but that be nice. Based on that, I've also written a Yacc-style grammar for text/plain[3] (exactly Yecc, an erlang implementation), but I have the same problem: QUOTED_VALUE is a terminal. Anyway, I strongly suggest this grammar to be part of the OCCI HTTP rendering specifications, maybe as an appendix. I've discovered (this week-end :) ) that JSON schemas specification exist, and their are implemented in a lot of libraries, JSON specification should then include a schema of this kind. Same for XML... Last but not least, we may agree on a reference meta-language to describe OCCI extension and include such description as appendix to each extension. AFAIK, XML is the most complete meta-language for this purpose. Comments welcome, Best regards, Jean [0] http://www.w3.org/TR/xmlschema-2/#built-in-datatypes [1] http://www.aeolus-project.org/ [2] http://www.upsilon.cc/~zack/research/publications/sefm2012-aeolus.pdf [3] https://github.com/jeanparpaillon/erocci/blob/master/src/rendering/occi_par… -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

3 4

Versioning RESTful Services v2 | Howard Dierking
by Sill, Alan 23 Sep '13

23 Sep '13

Thought you would be interested in the blog post at the following link, having to do with principles for API versioning Topic: Since publishing both the REST Fundamentals course as well as my previous post on RESTful API versioning, I%u2019ve had the opportunity to think more about versioning in practice as I've been a part of designing the next major revision to the NuGet API (v3). This has been very helpful for a couple of reasons, but the most important one is that NuGet is a real application that has both non-trivial scale requirements and a number of different clients %u2013 many of which are not controlled by the NuGet core team. Going through this API design exercise has both validated some of my earlier thinking as well as revised some other thinking. The point of this post is to lay some of that out. ... (content of the article here) ... [So] I’ll add another principle (well, borrowed it from Fielding actually): all important resources must have URIs This ends up impacting versioning strategies as follows: • If you’re adding only, go ahead and just add it to the representation. Your clients should ignore what they don’t understand • If you’re making a breaking change to the representation or changing the meaning of the underlying resource, create a new resource with a new name (URI) • Use content negotiation in such a way that it can provide an optimized path to resources, but always give the client control (by way of links) to make different choices Link: http://codebetter.com/howarddierking/2013/09/12/versioning-restful-services… Opinions welcome. Best regards, Alan

1 0

Slides about OCCI monitoring
by Augusto Ciuffoletti 21 Sep '13

21 Sep '13

Dear all, I will not be in Madrid next week, but I have prepared some slides that may be useful for those that want to know the content of the document about cloud monitoring that is currently under discussion. The slides start by giving the basic concepts, proceed with a description of the entities that implement the monitoring infrastructure, and conclude with a step by step definition of a non-trivial monitoring infrastructure. This is the link: http://www.slideshare.net/AugustoCiuffoletti/2013-03-occimonitoring-26159563 Comments are welcome, and I wish you a good time in Madrid. -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

3 4

testdyso --> doyouspeakocci (and please join project)
by Sill, Alan 21 Sep '13

21 Sep '13

Hi all, I've redeployed Alexander's "Do You Speak OCCI?" tester at http://testdyso.appspot.com while we try to figure out why the old "doyouspeakocci" name seems no longer to be available to him or to anyone else. This is the same as the current source available at https://github.com/lxndrp/doyouspeakocci with only the application name changed. Using it in practice has shown that while it is still really useful, it could use some more robust error condition flagging and reporting, for example trapping when the remote server fails to return location headers or replies with deprecated "X-..." ones as in the example that we ran into today. It is also useful locally - just download it, change as needed and deploy in your own local GoogleAppEngine Launcher. That way you can look at the logs locally, even more useful than running it on the web. Feel free to join the project at the source link above, add yourself to the mailing list, etc. I will probably turn some students at TTU loose on it as a learning exercise once things get a little further along. Just remember that the application name on appspot has changed for now. Alan

1 0

Reminder: OCCI bi-weekly conference call @ 4pm UTC, 12 EDT, 6 CEST
by Metsch, ThijsX 18 Sep '13

18 Sep '13

Hi all, Quick reminder for today's conference call where we'll be walking through the ongoing topics: https://plus.google.com/hangouts/_/calendar/dG1ldHNjaEBnbWFpbC5jb20.m5bt6ac… Talk to later today! Cheers, -Thijs ------------------------------------------------------------- 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 3

Fwd: Fwd: CloudPlugfest Dial-In & WebEx Details - Santa Clara
by Sill, Alan 16 Sep '13

16 Sep '13

NB as below. Alan Begin forwarded message: From: Mark Carlson <mark.carlson(a)oracle.com<mailto:mark.carlson@oracle.com>> Date: September 16, 2013, 3:57:19 PM GMT+02:00 To: "Sill, Alan" <alan.sill(a)ttu.edu<mailto:alan.sill@ttu.edu>> Subject: Re: [occi-wg] Fwd: CloudPlugfest Dial-In & WebEx Details - Santa Clara Alan, This is just for registered attendees.... -- mark On Sep 16, 2013, at 6:46 AM, "Sill, Alan" <alan.sill(a)ttu.edu<mailto:alan.sill@ttu.edu>> wrote: How to connect to the Cloud Interoperability Week activities in Santa Clara this week. They are working towards a CDMI + CIMI + OVF (and maybe CAMP) demo, similar to the ones we have done using OCCI. Connection details for the local OCCI WG session at OGF 39 and for the Madrid sessions (and whether those for these latter Cloud Plugfest sessions and workshop are the same or not) will be sent once we get the Madrid session folks together here. Alan Begin forwarded message: From: "Mancuso, Tom" <tom.mancuso(a)snia.org<mailto:tom.mancuso@snia.org>> Date: September 16, 2013, 3:37:51 PM GMT+02:00 To: "Mark. Carlson (mark.carlson(a)oracle.com<mailto:mark.carlson@oracle.com>)" <mark.carlson(a)oracle.com<mailto:mark.carlson@oracle.com>>, "dslik(a)netapp.com<mailto:dslik@netapp.com>" <dslik(a)netapp.com<mailto:dslik@netapp.com>> Cc: "planners(a)cloudplugfest.org<mailto:planners@cloudplugfest.org>" <planners(a)cloudplugfest.org<mailto:planners@cloudplugfest.org>>, "Meleedy, Michael" <michael.meleedy(a)snia.org<mailto:michael.meleedy@snia.org>>, "Jones, Arnold" <arnold.jones(a)snia.org<mailto:arnold.jones@snia.org>> Subject: Latest Reg List and CloudPlugfest Dial-In & WebEx Details - Santa Clara Wiki address: https://services.plugtests.net/wiki/2013-CloudWeek/ WebEx: (Meetings are set run for 8 hours/day as needed) http://snia.webex.com Topic: CloudPlugfest- Santa Clara Meeting number: 792 810 112 Meeting password: cloud2013 Host key: 529380 Teleconference: US Toll Free Access - 1-866-439-4480 US Toll Access - 1-212-786-7191 Spain Toll English - +34(0)917889871 Spain Toll Free English - 800099004 Participant PIN Code - 16651018# (or 87763154# to moderate) International Access Numbers & Control Codes: http://www.snia.org/international/support Tom Mancuso Senior Program Manager, SMI Storage Networking Industry Association _______________________________________ SNIA Mobile: 719.491.2614 tom.mancuso(a)snia.org<mailto:tom.mancuso@snia.org> www.snia.org<http://www.snia.org/> Follow SNIA: [twitter-128x128.png]<http://www.snia.org/about/socialmedia/twitter> [facebookf.png] <http://www.facebook.com/SNIA.ORG> [linkedin_256.png] <http://www.linkedin.com/company/snia> [blog.gif] <http://www.sniablog.org/> [video.gif] <http://www.snia.org/news_events/multimedia> <image001.png> <image002.png> <image003.png> <image004.png> <image005.png> _______________________________________________ occi-wg mailing list occi-wg(a)ogf.org<mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg

1 0

Fwd: CloudPlugfest Dial-In & WebEx Details - Santa Clara
by Sill, Alan 16 Sep '13

16 Sep '13

How to connect to the Cloud Interoperability Week activities in Santa Clara this week. They are working towards a CDMI + CIMI + OVF (and maybe CAMP) demo, similar to the ones we have done using OCCI. Connection details for the local OCCI WG session at OGF 39 and for the Madrid sessions (and whether those for these latter Cloud Plugfest sessions and workshop are the same or not) will be sent once we get the Madrid session folks together here. Alan Begin forwarded message: From: "Mancuso, Tom" <tom.mancuso(a)snia.org<mailto:tom.mancuso@snia.org>> Date: September 16, 2013, 3:37:51 PM GMT+02:00 To: "Mark. Carlson (mark.carlson(a)oracle.com<mailto:mark.carlson@oracle.com>)" <mark.carlson(a)oracle.com<mailto:mark.carlson@oracle.com>>, "dslik(a)netapp.com<mailto:dslik@netapp.com>" <dslik(a)netapp.com<mailto:dslik@netapp.com>> Cc: "planners(a)cloudplugfest.org<mailto:planners@cloudplugfest.org>" <planners(a)cloudplugfest.org<mailto:planners@cloudplugfest.org>>, "Meleedy, Michael" <michael.meleedy(a)snia.org<mailto:michael.meleedy@snia.org>>, "Jones, Arnold" <arnold.jones(a)snia.org<mailto:arnold.jones@snia.org>> Subject: Latest Reg List and CloudPlugfest Dial-In & WebEx Details - Santa Clara Wiki address: https://services.plugtests.net/wiki/2013-CloudWeek/ WebEx: (Meetings are set run for 8 hours/day as needed) http://snia.webex.com Topic: CloudPlugfest- Santa Clara Meeting number: 792 810 112 Meeting password: cloud2013 Host key: 529380 Teleconference: US Toll Free Access - 1-866-439-4480 US Toll Access - 1-212-786-7191 Spain Toll English - +34(0)917889871 Spain Toll Free English - 800099004 Participant PIN Code - 16651018# (or 87763154# to moderate) International Access Numbers & Control Codes: http://www.snia.org/international/support Tom Mancuso Senior Program Manager, SMI Storage Networking Industry Association _______________________________________ SNIA Mobile: 719.491.2614 tom.mancuso(a)snia.org<mailto:tom.mancuso@snia.org> www.snia.org<http://www.snia.org/> Follow SNIA: [twitter-128x128.png]<http://www.snia.org/about/socialmedia/twitter> [facebookf.png] <http://www.facebook.com/SNIA.ORG> [linkedin_256.png] <http://www.linkedin.com/company/snia> [blog.gif] <http://www.sniablog.org/> [video.gif] <http://www.snia.org/news_events/multimedia>

1 0