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

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

Preliminary Cloud Plugfest web site draft - comments welcome
by Alan Sill 10 May '12

10 May '12

We have made a copy of the prototype project site for the ongoing Cloud Plugfest series, deliberately in non-OGF neutral web space, available for viewing at the following URL: http://draft.cloudplugfest.org The colors, logo, and site layout are subject to change, but we would like feedback on the content and especially links to results and/or information to post on the results from previous plugfests. Anything in the public domain is welcome. We have also started an OGF Redmine community-group project page to support work in this area. Please feel free to register for an account in the OGF Redmine, join the project and make use of the materials there and the opportunity to put code into the repository that supports the ongoing plugfest work, as long as it is compatible with the open, publicly viewable nature of submissions to the OGF community. http://redmine.ogf.org/projects/cloud-plugfest-cg Alan P.S.: Volunteers to move the OCCI-WG content from Sourceforge to Redmine and to create and maintain a new set of occi-wg tools in the OGF Redmine would be welcome! 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 0

Fwd: [Openstack] 3rd Party APIs
by Alan Sill 08 May '12

08 May '12

FYI - please feel free to join the Openstack list (and the openstack-dev list if that gets going) and contribute your knowledge and implementations as suggested and requested below. Alan Begin forwarded message: > From: Mark McLoughlin <markmc(a)redhat.com> > Subject: Re: [Openstack] 3rd Party APIs > Date: May 8, 2012 9:58:45 AM CDT > To: "openstack(a)lists.launchpad.net" <openstack(a)lists.launchpad.net> > Cc: "openstack-poc(a)lists.launchpad.net" <openstack-poc(a)lists.launchpad.net> > Reply-To: Mark McLoughlin <markmc(a)redhat.com> > > Hey, > > I just realised there's a thread on the openstack-poc list about how > OpenStack should view implementations of APIs other than the OpenStack > API: > > https://lists.launchpad.net/openstack-poc/msg00448.html > > (PPB members - please note that other folks can't subscribe to the POC > list. If you want an open discussion on something, the openstack-poc > list isn't the place for it) > > > tl;dr - rather than actively discouraging folks from contributing native > API implementations, encourage them to resolve the current difficulties > with the EC2 API and their work as a test case for feature/subsystem > branch development process. > > > The discussion is fairly complex and seems to degenerate into an overly > general "what is and is not core" discussion. There also seems to be a > sense of urgency around finding a final solution here, which I don't > fully understand. The truth is we don't know the answer. We just need to > have some rough idea of what we're trying to achieve and figure out the > thing we want to try next. We'll likely have to try a bunch of stuff > before finding one that works. > > What I'd like to see us get to is: > > Deep overlap between the OpenStack developer community and the > community of folks drafting whatever IaaS standard(s) wind up being > dominant. > > e.g. prominent, active Nova developers developers contributing to the > CIMI or OCCI standards and bringing the needs of OpenStack to the > standard and bringing ideas from the standards process to OpenStack. > > This isn't a question of asking existing OpenStack developers to join > these standards bodies. It's about enabling members of those standards > bodies to become as much a part of OpenStack as any other developer. > > How to do that? Encourage members the various standards communities to > actively contribute an implementation of their standard to OpenStack > and, more importantly, stick around to become an ongoing active member > of the OpenStack developer community. > > If this worked out, OpenStack would gain new developers, new ideas and > would be seen as the best place to do new work around IaaS APIs. > > > AFAICT nova-core has two major concerns with the EC2 API - 1) currently > having to make a change once in the OpenStack API and again in the EC2 > API and 2) the EC2 isn't maintenance isn't sufficiently active. > > I think a lot of the urgency around this discussion is wanting to avoid > exacerbating the situation by adding another API. To me, the answer is > fairly simple. We cannot accept a new API until these concerns are > addressed: > > 1) The amount of duplication between the OpenStack, EC2 and any > proposed API needs to be significantly reduced > > 2) The developers of any proposed new API need to demonstrate a > commitment (through their work) to sticking around as active > OpenStack developers maintaining the API (perhaps as a subsystem > tree) > > That's a high bar, and I expect only seriously committed contributors > would meet it. In the meantime, those contributors can work on their > APIs as feature branches and encourage others to give feedback. > > > Two alternatives to the above are on the table. Firstly, implementing > these APIs as deltacloud-like proxy servers and blessing these as > "official" OpenStack products. IMHO, proxies are architecturally less > than ideal. Perhaps with enough engineering effort (including OpenStack > API additions) we can get to where they are almost on-par with a native > API, but I'm sceptical. > > The other option is to support these APIs with external plugins. For us > to get there, we need a stable library-like API that these plugins can > depend on. It's potentially an ideal solution, but I think we've a long > way to get there. A stepping stone is the re-factoring to reduce > duplication between APIs. > > > Cheers, > Mark. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack(a)lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp

1 0

Resource & OS templates retrieving
by John Giannelos 07 May '12

07 May '12

Hi, My name is John Giannelos and I am currently working on an OCCI implementation. After reading the OCCI specifications, I have a question regarding the Resource and OS templates. After registering each Resource and OS template available, as a mixin related to the categories "resource_tpl" and "os_tpl", how can we retrieve them? The specification says that every OCCI implementation must support a filtering mechanism, which filters the provided categories of the query. But every resource and os template is registered as a category itself, thus cannot be retrieved using this filtering mechanism. I would appreciate some help. Thanks in advance, John

4 7

Regarding Mixin relation and "accumulation" of attributes
by Ralf Nyren 07 May '12

07 May '12

Andy, you asked about whether a Mixin related to another Mixin will inherit the attributes. Please look at OCCI Core page 9: "Mixin Relationships A Mixin instance MAY be related to another Mixin instance for type classification purposes. For example a set of operating system templates, implemented as Mixin instances, could be related to an “OS-template” Mixin in order to help identification. Attributes and Actions defined by different Mixin instances are combined when Mixin relationships are present. ^^^^^^^^^^^ Therefore a resource instance associated with a particular Mixin will receive the additional capabilities defined by any related Mixin instances as well as those defined by the Mixin associated." Does this cover what you were after? Maybe it is unclear that "capabilities" refer to attributes as well? regards, Ralf

2 2

Fwd: New CIMI WIPs on DMTF public site
by Alan Sill 04 May '12

04 May '12

FYI - new CIMI Work-in-Progress (WIP) versions have been published. For details, please see links below. Thanks, Alan Begin forwarded message: > From: Winston Bumpus <wbumpus(a)vmware.com> > Date: May 4, 2012 1:49:35 PM CDT > To: "cmwg(a)dmtf.org" <cmwg(a)dmtf.org> > Subject: [cmwg] New CIMI WIPs on public site > > All, > > Thanks to your hard work the latest version (1.0.0d) CIMI spec and > CIMI primer is now available publically at http://dmtf.org/standards/cloud > > Winston Bumpus > President, DMTF > www.dmtf.org > Director of Standards Architecture > VMware, Inc. > 650.427.2787 | Office > 650.644.7968 | Mobile > www.VMware.com/go/standards >

1 0

JSON Rendering
by Feldhaus, Florian 04 May '12

04 May '12

Hi, once again I would like to reiterate the JSON rendering. First a short overview what Alexander and I think are the main points we should address: - remove all HTTP Rendering specific parts from the JSON rendering - make the JSON rendering slim and remove everything which is not a representation of the OCCI model - consider using RFC 5988 "Web Linking" for collection information (e.g. index, next, previous,…) Examples: http://pastebin.com/ZK9Uf0K1 (Entities) http://pastebin.com/cKGw9pz6 (Categories) To keep the mail short, a detailed discussion can be found in the attached text document. 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 -----------------------------------------------------------------------------------

8 36

Fwd: [one-ecosystem] New component(OVF4ONE) for openenbula 2.2
by Feldhaus, Florian 03 May '12

03 May '12

FYI ------------------------------------------------------------------------------- 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 ----------------------------------------------------------------------------------- Anfang der weitergeleiteten E-Mail: > Umgeleitet von: <florian.feldhaus(a)tu-dortmund.de> > Von: <Kanchanna.RamasamyBalraj(a)eng.it> > Betreff: [one-ecosystem] New component(OVF4ONE) for openenbula 2.2 > Datum: 3. Mai 2012 12:08:01 MESZ > An: <community-manager(a)opennebula.org>, <ecosystem(a)lists.opennebula.org> > Kopie: <Paolo.Fabriani(a)eng.it>, <saint(a)eng.it> > > Dear Opennebula team, > We have realised a tool that provides OCCI interface that accepts OVF(Open virtualization format) input on top of the Opennebula OCA interface. Please find further details on the tool below. > > Name of the Component: OVF4ONE > > URL of the Component: http://grids15.eng.it/svn/main/ovf4one > > Brief Description (30 words max): This software is a Java implementation of OCCI according to GFD.184 using OVF messages and OpenNebula as back end.Technically speaking, ovf4one is an OCCI to OCA gateway, translating RESTful calls to the OCCI methods into OCA RESTful calls and the OVF XML message is translated into OpenNebula VM templates. .This project has been realised as part of Venus-C EU project > > Type (tool/extension/plugin): Tool > > License (proprietary/OSS): LGPL license > > OpenNebula Version: 2.2 > > Author (person or organization developing the code): Gian Uberto Lauri(Engineering Ingegneria Informatica Spa) > > E-mail: saint(a)eng.it, kanramas(a)eng.it > > Regards, > Kanchanna > _______________________________________________ > Ecosystem mailing list > Ecosystem(a)lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/ecosystem-opennebula.org

2 1