- occi-wg - lists.ogf.org

Fwd: [CSC] Cloud Interoperability Week - CloudPlugfest Test Report
by Sill, Alan 18 Oct '13

18 Oct '13

Results from the September 2013 Cloud Plugfest, FYI. Alan Begin forwarded message: From: Silvia Almagia <Silvia.Almagia(a)ETSI.ORG<mailto:Silvia.Almagia@ETSI.ORG>> Date: October 18, 2013 at 7:10:27 AM CDT To: "CLOUD_STANDARDS_COORDINATION(a)LIST.ETSI.ORG<mailto:CLOUD_STANDARDS_COORDINATION@LIST.ETSI.ORG>" <CLOUD_STANDARDS_COORDINATION(a)LIST.ETSI.ORG<mailto:CLOUD_STANDARDS_COORDINATION@LIST.ETSI.ORG>> Subject: [CSC] Cloud Interoperability Week - CloudPlugfest Test Report Reply-To: Silvia Almagia <Silvia.Almagia(a)ETSI.ORG<mailto:Silvia.Almagia@ETSI.ORG>> Dear CSC-ers, Please find attached the Test Report of the CloudPlugfest that was held during the Cloud Interoperability Week 16-20 September 2013 in Madrid and Santa Clara. Best regards, Silvia ------------------------------------------------------------------- Silvia ALMAGIA Technical Expert Centre for Testing and Interoperability (CTI) European Telecommunication Standards Institute (ETSI) Tel: +33 4 92 94 49 64 Mob: +33 6 69 70 68 86 www.etsi.org<http://www.etsi.org/> portal.etsi.org/cti P Please consider the environmental impact before printing this e-mail

1 0

Fwd: [CSC] List of standards
by Sill, Alan 18 Oct '13

18 Oct '13

OGF GFSG and other interested OGF members, Here is an intermediate list of standards and references compiled by the ETSI Cloud Standards Coordination team. This is part of their activities in what is intended and announced to be a public process. Wolfgang Ziegler has been attending these meetings on behalf of OGF. If you have input to offer, and/or would like to participate in the process yourself or provide references and links to other OGF output or documents of interest on this topic, please communicate with Wolfgang and/or send your input directly to the committee. Wolfgang, if you have any feedback from the committee as to their interests and/or any observations to offer, please feel free to do so. Thanks very much for helping to get OGF work into public view in an appropriate way. Alan Sill, TTU OGF VP of Standards Begin forwarded message: > From: Laurent Vreck <Laurent.Vreck(a)ETSI.ORG> > Subject: [CSC] List of standards > Date: October 17, 2013 12:33:49 PM CDT > To: <CLOUD_STANDARDS_COORDINATION(a)LIST.ETSI.ORG> > Reply-To: Laurent Vreck <Laurent.Vreck(a)ETSI.ORG> > > Attached is an interim version of the standards list. > Just sent out for backup purposes since it will be modified again tomorrow. > > Laurent > > ------------------------------------------------------------------- > Mail archive for CLOUD_STANDARDS_COORDINATION can be browsed at the following url : > http://list.etsi.org/CLOUD_STANDARDS_COORDINATION.html > To unsubscribe from this list send a mail to listserv(a)list.etsi.org > with the following text in the body: UNSUBSCRIBE CLOUD_STANDARDS_COORDINATION > ------------------------------------------------------------------- > > >

4 3

No confcall today.
by Metsch, Thijs 15 Oct '13

15 Oct '13

Hi all, Originally there is a call scheduled today. Sadly enough we have to postpone it as Andy and I are double booked. But please feel free to discuss open issues on the list. All the best, -Thijs Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Fwd: [p2302] CFP: IEEE Workshop on Cloud Computing Interclouds, Multiclouds, Federations, and Interoperability (Intercloud 2014)
by Sill, Alan 12 Oct '13

12 Oct '13

FYI Alan Begin forwarded message: From: David Bernstein <david(a)cloudstrategypartners.com<mailto:david@cloudstrategypartners.com>> Date: October 12, 2013 at 5:24:22 PM CDT To: p2302(a)mentor.ieee.org<mailto:p2302@mentor.ieee.org> Subject: [p2302] CFP: IEEE Workshop on Cloud Computing Interclouds, Multiclouds, Federations, and Interoperability (Intercloud 2014) Reply-To: p2302(a)mentor.ieee.org<mailto:p2302@mentor.ieee.org> IEEE Third International Workshop on Cloud Computing Interclouds, Multiclouds, Federations, and Interoperability (Intercloud 2014) http://intercloud.cloudcom.org Organised by Cloud Computing Association http://cloudcomputing.ieee.org Co-Sponsored by IEEE Cloud Computing Initiative CALL FOR PAPERS As part of IEEE International Conference on Cloud Engineering (IC2E) http://conferences.computer.org/IC2E/2014/ March 11, 2014 Boston, Massachusetts, USA Submission Deadline: November 15, 2013 SCOPE AND OBJECTIVES Advances in processing, communication and systems/middleware technologies have led us to new paradigms and platforms for computing – in the form of Cloud Computing. That in its own turn creates a basis for the Big Data and Data intensive technologies. Cloud Computing from Cloud Service Providers is a burgeoning market with a wide variety to choose from, including some of the most notable names in Internet and IT today. Cloud Computing is the go-to platform now for datacenter architecture, scalable application hosting, new application development, and mobile app platform. While cloud Computing enjoys a certain amount of application – or application architecture – portability, there are not really any interoperability standards or common practices in place. Security, SLA, and other concerns are still active areas of interest. Also, while Cloud Computing is different from Grid Computing, there is some Federation and Interoperability in the Grid community, are these appropriate to the Cloud Computing space. It is widely believed that the whole space of Clouds, Grids, and the Intercloud will federate and eventually converge. There are lessons to be learned from the early Internet work as well as Mobile Telephony. Some believe that SDN is the key to making this happen. This workshop focuses on techniques, experiences and lessons learned for interoperable services in Interclouds, Multiclouds, Federations, and Interoperability. This workshop aims at providing a forum to bring together researchers for sharing and exchanging Cloud computing related research, technologies, experience, and lessons for building Clouds with Intercloud, Multicloud, Federation, and Interoperability capabilities and services. The Workshop topics include (but are not limited to) the following: * Theory, frameworks, methodologies, architecture for Interclouds, Multiclouds, Federations, and Interoperability * Cloud Federation and Interoperability Protocols * Trust, Security, Identity for Interclouds, Multiclouds, Federations, and Interoperability * Virtual Private Cloud, IP-SEC, MPLS techniques for Domain Management * Grid Federation and Interoperability Protocols, Lessons Learned, As Applied to Clouds * Experimental Results of Distributed/Multiple Datacenter Cloud Coordination and Interoperability * Theory or Experimental Results of SDN used for Federations, and Interoperability * Semantic Web Services Definitions for Clouds Resources and Management * Using Big Data techniques to solve Federation Constraint based Resource Matching * Mobile Roaming applications for for Interclouds, Multiclouds, Federations, and Interoperability * Cloud and Grid Federation governance and regulatory issues * Traffic and load balancing across Federated and Interoperable Clouds * QoS/SLA in Federated and Interoperable Clouds * Converged Implementations of Clouds and Grids * PaaS for Interclouds, Multiclouds, Federations, and Interoperability * Interoperable cloud based infrastructures for Big Data applications * Management operations, discovery, configuration, provisioning * Geo-balancing for Interclouds, Multiclouds, Federations, and Interoperability * Compliance, Reference Definitions and Semantics, for Interclouds, Multiclouds, Federations, and Interoperability * Testbeds for Interclouds, Multiclouds, Federations, and Interoperability PAPER SUBMISSIONS Manuscripts should be prepared in 10-point font using the IEEE 8.5" x 11" two-column format. The full manuscript should be at most 7 pages. All papers should be in PDF. Please include page numbers on all submissions to make it easier for reviewers to provide helpful comments. Paper submission http://www.easychair.org/conferences/?conf=intercloud2014 A paper submitted to Intercloud2014 cannot be under review for any other conference or journal during the entire time it is considered for Intercloud2014, and it must be substantially different from any previously published work. All submissions are peer-reviewed. The IEEE Computer Society Conference Publishing Services will publish accepted papers. Each paper will receive a minimum of three reviews. Papers will be selected based on their originality, relevance, technical clarity and presentation. Authors of accepted papers must guarantee that their papers will be registered and presented at the workshop. If you have any questions about paper submission or the workshop, please contact the organizer. IMPORTANT DATES Paper Submissions: November 30, 2013 Acceptance Notification: December 13, 2013 Camera Ready Papers and Registration Due: January 17, 2014 Conference Dates: March 11, 2014 WORKSHOP ORGANIZER (S) David Bernstein Founder/Chief Architect, IEEE P2302 Intercloud Standards Working Group and Global Testbed Project Cloud Strategy Partners, LLC Yuri Demchenko University of Amsterdam Chunming Rong University of Stavanger International Program Committee See http://intercloud.cloudcom.org If you have any questions about the IC2E 2014 conference paper submission, please contact Conference Program Chair or consult the conference web site at http://conferences.computer.org/IC2E/2014/

1 0

RAML - RESTful API modeling language
by Sill, Alan 02 Oct '13

02 Oct '13

Thoughts? (My question is: what can you do with a RAML-formatted API description once you have it? Is it just an exercise and sanity check of your API?) Topic: RAML stands for RESTful API Modeling Language. It's a way of describing practically-RESTful APIs in a way that's highly readable by both humans and computers. We say "practically RESTful" because in the real world, very few APIs today actually are. RAML isn't strict: in the end it is only describing HTTP with a few higher-level (optional) constructs. RAML is a non-proprietary, vendor-neutral open spec. The aim is to help our current API ecosystem and solve immediate problems, and then gently encourage ever-better API patterns. \ Links: http://raml.org/about.html https://github.com/raml-org/raml-spec Alan

2 1

XML for monitoring
by Augusto Ciuffoletti 02 Oct '13

02 Oct '13

Hi Jean and all, so, I tried to work out the XML for the monitoring extension. Is it more or less what you expect it to be? Augusto -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

2 1

Conference call today @ 4pm UTC
by Metsch, Thijs 01 Oct '13

01 Oct '13

Hi all, Here is the link to the google hangout for the call later today: http://bit.ly/19jU8lX Cheers, -Thijs Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

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