- occi-wg - lists.ogf.org

OCCI JSON Rendering Draft v2
by Feldhaus, Florian 27 May '12

27 May '12

I updated the OCCI JSON Rendering with the input from Ralf. Heres the list of changes: - cleanup of examples - detailed examples in separate section - hightlighting of examples through minted latex package - moved title, summary and id to top level in resource and link Especially the last change has a lot of implications. See my explanation in the other thread, why I would do it this way. Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus(a)gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------

3 2

June 2012 Cloud Plugfest - Registration is now open
by Mancuso, Tom 23 May '12

23 May '12

All, The next OGF/SNIA organized Cloud Plugfest is scheduled for June 14 - 17 with locations in Shenzhen, CN, Amsterdam, NL, and Chicago, IL. This event is the 5th in the series and is proudly co-sponsored by Cleversafe<http://www.cleversafe.com/>, Huawei<http://www.huawei.com/en/>, OGF<http://www.ogf.org/> and the SNIA Cloud Storage Initiative<http://www.snia.org/forums/csi>, with ETSI<http://www.etsi.org/> providing testing support. Registered participants may attend any of the physical locations or remotely via dial-in. Registration is free and open to all who are looking to implement cloud standards such as CDMI or OCCI. Seating is limited to 5 - 15 seats at some locations and will be filled on a first-registered-first-served basis. For more information, or to register to attend, please visit www.cloudplugfest.org<http://www.cloudplugfest.org> and complete the registration form. The February/March Cloud Plugfest held in Dusseldorf, DE attracted over 35 participants. The www.cloudplugfest.org<http://www.cloudplugfest.org> website is a new tool being deployed for this activity and will be updated and expanded to become a one-stop resource for cloud plugfest activities, so please bear with us as this site continues to evolve. Plugfest Logistics Contacts: * Shenzhen, CN - Mark Carlson/SNIA - mark.carlson(a)oracle.com<mailto:mark.carlson@oracle.com> * Amsterdam, NL - Joel Repogle/OGF - replogle(a)ogf.org<mailto:replogle@ogf.org> * Chicago, IL - Chad Thibodeau/SNIA - cthibodeau(a)cleversafe.com<mailto:cthibodeau@cleversafe.com> * Remote - Tom Mancuso/SNIA - tom.mancuso(a)snia.org<mailto:tom.mancuso@snia.org> Regards, - Tom 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>

1 0

OCCI implementation for Synnefo IaaS
by John Giannelos 23 May '12

23 May '12

Dear OCCI members, I would like to make an announcement about a new OCCI implementation. Here in GRNET [1] we are currently developing an API translation proxy in order Synnefo [2], our IaaS cloud management software to be compatible with OCCI specifications. Synnefo can be seen in action, powering the ~okeanos service, at http://okeanos.grnet.gr. ~okeanos aims to deliver advanced IaaS for the Greek academic and research community. Some resources about our work regarding OCCI can be found here [3]. *About snf-occi* snf-occi implements an API bridge between OCCI and OpenStack APIs using the kamaki [4] client library and associated CLI tool to translate between interfaces. So far, the Compute part of the implementation has been completed, with Network and Storage support soon to follow. We hope snf-occi will prove helpful for other OpenStack-compatible projects to gain interoperability with OCCI, with little (or no) changes to our initial work. I would also like to know whether it will be possible to make our project public in occi-wg blog for people who may be interested but are not subscribed to this mailing list. Thanks, The ~okeanos team! [1] http://www.grnet.gr [2] http://docs.dev.grnet.gr/synnefo [3] http://docs.dev.grnet.gr/snf-occi/latest/index.html [4] http://docs.dev.grnet.gr/kamaki/latest/index.html

4 4

Cloud Plugfest planning meeting
by Alan Sill 22 May '12

22 May '12

Going on now: 1-866-439-4480 US - Toll Access - 1-212-786-7191 Participant PIN Code - 16651018# International Access Numbers: http://www.snia.org/international/support WebEx - http://snia.webex.com Meeting number: 793 124 513 Meeting password: cloud2012 Host key: 473844

1 0

JSON Document
by Edmonds Andrew (edmo) 18 May '12

18 May '12

First, Great work! Here are some editorial comments: - Please ensure line breaks at col 80 - The pdf build is broken. There is a missing dependency of "! LaTeX Error: File `json_rendering.out.pyg' not found." Please fix with a README with directions on installing the dependency. - In all tables, 'name resources' doesn't make sense. Possibly should be 'named resources'? If so I can make the edits or it's at your pleasure :-) - 'Necessity' in all tables. This is some what out of step with existing specs. Can it be aligned along 'Mutability' and 'Multiplicity' as in the existing OCCI specification series? - I've made and committed some minor changes. Review at your leisure. HTH, Andy Andy Edmonds Senior Researcher Institute of Information Technology Zurich University of Applied Sciences http://andy.edmonds.be, @dizz

3 3

Fwd: [Openstack] Third Party APIs
by Alan Sill 17 May '12

17 May '12

FYI. Comments (especially on the openstack list) welcome... Alan Begin forwarded message: > From: Vishvananda Ishaya <vishvananda(a)gmail.com> > Date: May 17, 2012 1:18:19 PM CDT > To: "openstack (openstack(a)lists.launchpad.net)" <openstack(a)lists.launchpad.net > > > Subject: [Openstack] Third Party APIs > > Hello Everyone, > > In the ppb meeting last week[1] we discussed third party apis and > decided that the policy is not to include them in core. > Specifically the motion that passed is: > > An OpenStack project will support an official API in it's core > implementation (the OpenStack API). other APIs will be implemented > external to core. the core project will expose stable, complete, > performant interfaces so that 3rd party APIs can be implemented in a > complete and performant manner. > > So now that we have settled on a long term goal for third party > apis, we need to deal with the short term. We do have a stable > interface in Nova in the form of the OpenStack API but it remains to > be seen whether it is complete and performant enough to allow other > apis to be layered on top of it. > > Ultimately, I would like to see a stable internal python api that > the other apis could speak through (including the OpenStack api > layer), but it will probably take a while to get there. In the short > term I see three possibilities for third party apis. > > 1 Proxy Layer > > This is the approach being taken by AWSOME, and it is definitely the > easiest to maintain. It has some big advantages, like allowing new > apis deployed in a completely decoupled manner. The main potential > drawbacks are performance and an incomplete mapping of concepts from > one api to another. This will most likely require adding OpenStack > api extensions to support some of the extra features in other apis > > 2 Separate Project that talks to internal apis > > It is possible to write a separate component that imports the > compute.api in nova and uses it directly. This will deal with the > performance issues of the above approach, but it runs the risk of > being broken if the compute.api changes over the course of the > release. The advantage of this approach is it will drive > requirements for having a stable/versioned internal api. In this > model, automated testing would be necessary to alert any breakages. > > 3 Feature Branch in Core > > We are doing some work to support Feature and Subsystem branches in > our CI system. 3rd party apis could live in a feature branch so that > they can be tested using our CI infrastructure. This is very similar > to the above solution, and gives us a temporary place to do > development until the internal apis are more stable. Changes to > internal apis and 3rd party apis could be done concurrently in the > branch and tested. Once the branch has stabilized, the updates could > be pushed into the internal apis in nova, and the 3rd party api > could grow up into its own project like option 2 > > > It may be that there are other options that I haven't thought of, > but regardless of the approach taken by the various 3rd party apis, > I think it is valuable for us all to work together on stabilizing > the internal apis. I'd like the ec2 api to be able to live > separately as well. > > Vish > > [1] http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-me…

1 0

"SLA-Enabled Infrastructure Management" Abstract - SpringerLink
by Alan Sill 16 May '12

16 May '12

Thought you would be interested in the following link. Topic: SLA-Enabled Infrastructure Management Abstract This chapter documents a successful reference implementation of an SLA- enabled compute infrastructure. Limitations of current Infrastructure as a Service (IaaS) offerings are discussed, and an SLA-enabled implementation is introduced. Infrastructure SLA and services managers have been developed, as have extensions to Apache Tashi [11] and a low- level monitoring system. Efforts to develop a generic open interface to heterogenous infrastructure have helped to create the recently published Open Cloud Computing Interface (OCCI) [2]. Link: http://www.springerlink.com/content/n300405h87845124/ Alan Alan Sill, Ph.D 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 : ====================================================================

2 1

Draft Cloud Plugfest web site updated
by Alan Sill 16 May '12

16 May '12

A draft copy of the soon-to-launch Cloud Plugfest web site is available now at http://draft.cloudplugfest.org/ Changes from the last update include an updated draft of the logo (soon to be final), some improved layout and information and several updated links. Things we still need you to suggest or to put in (for those of you who have access to the web site) include better links to results and testing frameworks used, some examples from past plugfests, some improvements to contact information and some detailed information for the next events. Comments and contributions are welcome! Alan

2 2

[cloudtwg] Groups - Event "Cloud Plugfest Planning Meeting" modified
by Thomas Mancuso 14 May '12

14 May '12

Submitter's message Cloud Plugfest Planning Call Reminder -- Mr. Thomas Mancuso ----------------- Event Title: Cloud Plugfest Planning Meeting Date: Tuesday, 15 May 2012, 08:00am - 09:00am PT Description US – Toll Free Access - 1-866-439-4480 US - Toll Access - 1-212-786-7191 Participant PIN Code - 16651018# (or 87763154#) International Access Numbers: http://www.snia.org/international/support WebEx - http://snia.webex.com Meeting number: 793 124 513 Meeting password: cloud2012 Host key: 473844 View Details : https://members.snia.org/apps/org/workgroup/cloudtwg/event.php?event_id=456… ----------------- Agenda   - Lcoal logistics (still some missing items) - Agenda development (synch meetings & presentations) - Testing plans (tools, methods & scheduling) Owner: Mr. Thomas Mancuso Group: TWG: Cloud Storage Sharing: This event is shared with the Storage Networking Industry Association (General Membership) group.

1 0

OCCI JSON Rendering Draft
by Feldhaus, Florian 11 May '12

11 May '12

Hi all, I went through the JSON rendering and now there is a first more or less consistent version. I still have to improve some parts and prove read everything, but I wanted to discuss a few points with you beforehand. Locations - do UUIDs have to be globally unique, unique for all resources within a provider, or for all resources of a certain kind? -> I would prefer if we don't restrict this too much, thus it would be sufficient to restrict in OCCI Core, that UUIDs are unique for all resources of a certain kind for one OCCI endpoint. The UUID is created by the backend (underlying service provider) or with information from it. Thus, if the resource is migrated to a different service provider, it gets a different UUID anyway. - I'm not too happy with having the location being part of the kind/mixin rendering, as it is specific to the HTTP representation of the OCCI objects. I thought we might be able to introduce some guideline to derive the location from the term of the kind/mixin and it's related kinds/mixins (e.g. term recursively prepended by term of related kind/mixin). The only problem is, that mixins can have multiple relations. Thus we might have multiple locations for the same mixin. I don't see a problem with it, but it might lead to confusion. Link - for Target and Source the URI is sufficient, all further information can be retrieved by the client. There may also be mechanisms to ask the server to directly supply all resources connected via links. But that should be taken care of in HTTP rendering then. - Source is optional when rendered within resource. Then the link definition is the same for top level link renderings and link renderings within resources. Mixins - can mixins be related to kinds? -> I have a resource template as example and was wondering, how one would specify occi.compute.core for this template. If the mixin is related to compute, the attributes are all derived from the compute kind description and can be set to new defaults with the mixin. Action - should action really not be derived from category? -> I don't see any reason for the current solution (action containing a category). It would be much more consistent, if the Action would also be derived from Category. Attribute description - moved pattern and minimum / maximum out of type and into attribute description. This makes it more compatible with JSON schema Formatting - Currently the JSON examples are a bit hard to read. Maybe we could use the LaTeX package "minted" to do automatic highlighting? Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus(a)gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------

3 3