- occi-wg - lists.ogf.org

Re: [occi-wg] OCCI specification document
by Richard Davies 18 Aug '09

18 Aug '09

Hi all, Some brief comments after reading through the current (23 July) draft specification. Cheers, Richard. 2.3 Operations As described, Create is form-encoded, Retrieve is in application/occi+X, Update is in application/occi+X, Delete doesn't need a format, and Requests are form-encoded. I'd like us to also support application/occi+X for Create and Requests so that it's possible to write a client which only knows about a single format rather than having to implement at least two (form + one occi+X). 5. Nouns and attributes You'll need to make storage.size a Float, like compute.memory.size to allow drives below 1 GB (e.g. CD images). Alternatively (and better in my view), you could turn all of Floats into integers and describe them in the basic units - bytes, hertz, etc. Compute and storage resources need better status and support for being transient or persistent (a cloud could support both models, so needs to be told which a given resource will be, since the semantics are different when a server shuts down). I'd suggest: - Compute: add a 'status', which is 'active', 'stopped', etc. (maybe 5.2.1 state machine handles this? But the section is empty). - Compute: add a 'compute.type'? which is Enum(transient, persistent). - Storage: add a 'status' which is 'mounted', 'inactive', etc. (again, does 5.2.1 handle this?) - Storage: reliability isn't the same as transient/persistent. A persistent storage is one which isn't destroyed when the compute shuts down. It could still be on RAID, local disk, SAN, etc. So split out 'storage.type'? which is Enum(transient, persistent) from storage.reliability For networks, I feel there's missing content: - There is no mechanism described for static IPs on the public internet - The network.ipv4 is almost enough to run a DHCP server, but not quite. You'd really need name servers too. What is the hostname attribute in table 7? Is this just an example? I don't really see it as a common attribute, so that networks and storage have a hostname... I definitely feel that the compute.memory.speed, compute.memory.reliability and storage.reliability are less important than the other attributes described. 4.4.3 Links I'd like to see a little more detail here on how I specify the interface by which compute is linked to storage or network. (e.g. eth0, eth1, sda, sdb, etc). Presumably this will end up in the link[i].rel field? Will we specify canonical interface names for OCCI or allow each cloud to chose its own (eth0 vs. Local Area Network, sda vs hda, etc.)? How will a compute resource specify which of many linked storage resources it should boot from? 4.2 Collections "Operations that return multiple resources are rendered ..." shall we write "Operations which COULD return multiple resources..." to make it clear that Atom is always returned, even if there is a single result? Or should we explicitly say that single results are NOT returned as Atom.

4 5

OCCI specification document
by Thijs Metsch 18 Aug '09

18 Aug '09

Hi @all, The current version of the OCCI specification can be found here: http://forge.ogf.org/sf/go/doc15731?nav=1 Please have a look with a special look on the attributes defined in the document? Are any missing? Are there to much? What about the naming? We will be working on the document in the next days to push it further to get it done for OGF27. So more details and information to come. For now comments and ideas about the attributes are more then welcome! All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

5 8

Some notes on work done in the background
by Thijs Metsch 14 Aug '09

14 Aug '09

Hi, Most of you might know that the wiki on http://www.cloud-standards.org tries to give an overview of all Cloud standards. Especially with a focus on collaboration! There is also a diagram showing the positioning of all the cloud standards: http://cloud-standards.org/wiki/index.php?title=Cloud_standards_positioning It is a first short but looking promising. Next to that talks with the Cloud group inside of SNIA are going on - we are probably going to have a whitepaper describing the how OCCI and SNIA can work together. There if not much going on on the DMTF front currently. OGF itself is heavily engaged in pushing OCCI and other topics. For example several guys are currently at the CloudWorld (You might have seen the email from Joel about it - there is a OCCI one pager btw). Next to that OGF talks to many other organizations and goverments about Cloud Standards and howto collaborate. Finally OCCI itself is represented pretty good as well: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Presentations I just wanted to give you all an update of what is going on in the background. Of cause we are also working on our specification so stay tuned. All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

gridforge is currently unreachable
by Thijs Metsch 11 Aug '09

11 Aug '09

Hi It looks like that the OGF server is not reachable. I get an: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /sf/wiki/do/viewPage/projects.occi-wg/wiki/HomePage. Reason: Error reading from remote server @Joel: can you have look? All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

2 2

Reminder concall tomorrow: Wednesday 12, August 2009 at 4pm CET
by Thijs Metsch 11 Aug '09

11 Aug '09

Hi, Just a short reminder for or concall tomorrow at 4pm CET. The gridforge is currently down but I will prepare a agenda as soon as it is up again. The conference call data is enclosed below. All the best, -Thijs Participant passcode: 9032568 Dial in numbers: Country Toll Numbers Freephone/ Toll Free Number ARGENTINA 0800-777-0463 AUSTRALIA ADELAIDE: 61-8-8121-4868 1-800-249-288 AUSTRALIA BRISBANE: 61-7-3102-0970 1-800-249-288 AUSTRALIA CANBERRA: 61-2-6100-1970 1-800-249-288 AUSTRALIA MELBOURNE: 61-3-9010-7739 1-800-249-288 AUSTRALIA PERTH: 61-8-9467-5249 1-800-249-288 AUSTRALIA SYDNEY: 61-2-8205-8125 1-800-249-288 AUSTRIA 43-1-92-86-506 0800-005-029 BELGIUM 32-1-150-0314 0800-4-8680 BRAZIL 0800-7610674 CHILE 1230-020-2867 CHINA* 86-400-810-4766 10800-712-1433 10800-120-1433 COLOMBIA 01800-9-156430 CZECH REPUBLIC 420-2-25-98-56-54 800-700-173 DENMARK 45-7014-0280 8088-6132 ESTONIA 800-011-1089 FINLAND Land Line: 106-33-146 0-800-1-10100 FINLAND Mobile: 09-106-33-146 0-800-1-10100 FRANCE LYON: 33-4-26-69-12-81 080-563-9647 FRANCE MARSEILLE: 33-4-86-06-00-81 080-563-9647 FRANCE PARIS: 33-1-70-70-74-20 080-563-9647 GERMANY 49-69-2222-2566 0800-000-3441 GREECE 30-80-1-100-0683 00800-12-6973 HONG KONG 852-2286-5731 800-930-705 HUNGARY 06-800-18013 INDIA 000-800-852-1266 INDONESIA 001-803-011-3787 IRELAND 353-1-247-5253 1800-932-145 ISRAEL 1-80-9214916 ITALY 39-02-3600-3642 800-986-570 JAPAN OSAKA: 81-6-7739-4769 0034-800-400828 JAPAN TOKYO: 81-3-5539-5189 0034-800-400828 LATVIA 8000-3025 LUXEMBOURG 352-27-000-1360 MALAYSIA 1-800-80-2812 MEXICO 001-866-627-0574 NETHERLANDS 31-20-718-8533 0800-020-1392 NEW ZEALAND 64-9-970-4769 0800-449-823 NORWAY 47-21-59-00-59 800-15414 PANAMA 011-001-800-5072129 PERU 0800-53733 PHILIPPINES 63-2-858-3715 POLAND 00-800-1212021 PORTUGAL 8008-14061 RUSSIA 8-10-8002-9683011 SINGAPORE 65-6883-9228 800-120-4662 SLOVAK REPUBLIC 421-2-322-422-21 SOUTH AFRICA 080-09-80416 SOUTH KOREA 82-2-6744-1081 00798-14800-6860 SPAIN 34-91-414-62-98 800-099-810 SWEDEN 46-8-505-78-524 0200-890-106 SWITZERLAND 41-44-580-4389 0800-001-523 TAIWAN 886-2-2795-7377 00801-137-766 THAILAND 001-800-1206-65656 UNITED KINGDOM BIRMINGHAM: 44-121-210-9021 0808-238-6025 UNITED KINGDOM GLASGOW: 44-141-202-3221 0808-238-6025 UNITED KINGDOM LEEDS: 44-113-301-2121 0808-238-6025 UNITED KINGDOM LONDON: 44-20-7075-3246 0808-238-6025 UNITED KINGDOM MANCHESTER: 44-161-601-1421 0808-238-6025 URUGUAY 000-413-598-3415 USA 1-203-418-3122 866-692-3163 VENEZUELA 0800-1-00-3733

1 0

OCCI onepager
by Thijs Metsch 11 Aug '09

11 Aug '09

Hi, Currently OGF has a booth at the CloudWorld in San Fransisco (http://www.linuxworldexpo.com/) We are present as well with the attached onepager. If you are at CloudWorld say Hi and thanks to the guys from OGF :-) All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Offtopic: Rackspace open-sources its cloud interface
by Thijs Metsch 09 Aug '09

09 Aug '09

Hi, Apparently Rackspace is doing open -source: http://news.cnet.com/8301-13556_3-10293785-61.html?tag=mncol;posts Cheers, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

3 3

Re: [occi-wg] [Libcloud-list] API XML and Client Examples
by Sam Johnston 06 Aug '09

06 Aug '09

Bob, So the story behind OCCI is that I had planned to follow Google's example with GData 2.0 - it's essentially Atom Publishing Protocol (APP) extended for something like 16 different data types (everything from contacts to mails to videos) and it works nicely and has a bunch of clients already. Of course that ended in a religious war about the format-du-jour (XML vs JSON vs plain text) and we now actually have to do some real work (which is fine - the result should be better as a result). I wanted a draft by May (and still plan to deliver a final version by October) so now it's down to putting the current thinking on paper. I've spent a few months reading up on the various options, studying great books like RESTful Web Services and examining many existing APIs. I'm now trying to get as close to HTTP as possible, essentially making the API an "overlay" that brings resources (e.g. vmx, vmdk, ovf files) to life. It will likely be detected via /.well-known/occi/ (ala robots.txt) and should be compatible with everything from basic HTTP to Subversion, Git and WebDAV (with HTTP PUT et al required for interop). Alternative representations (e.g. console screenshots, OVF files, etc.) and interfaces (e.g. to the state machine) are advertised by Link: headers and a category scheme lifted from Atom allows for flexible categorisation of an arbitrary number of resources (as well as questions like "show me the windows servers in the US without patch KB123456 applied). We're also set to define a simple descriptor format following the footsteps of VMware's VMX (namespaced attribute value pairs - e.g "cpu.cores: 2") which will expose the usual IaaS functionality without the overhead of OVF/CIM (while retaining compatibility). This could prove particularly interesting for open source hypervisors. All of this is subject to change - right now I'm working on making it mesh together and tacking difficult problems like enumeration, templates, etc. Cheers, Sam On Sat, Aug 1, 2009 at 8:09 PM, Bob McWhirter <bmcwhirt(a)redhat.com> wrote: > Hiya Sam-- > > Yah, I saw that Rackspace also uses Link: type of headers, but I thus far > haven't seen the need in what I'm doing. Perhaps next week I'll come to the > realization as to why they're useful. :) > > We're designing an API primarily, along with some implementations, and aim > to have various language-binding clients for Ruby, Python, Java, etc. > > I'm sure there's some overlap with everyone doing cloud stuff. > > At this point, we're marching forward as fast as we can. I'll take a look > at the OCCI stuff, though, and see if we can't find some common ground. > > Thanks for the pointers, > > -Bob > > > On Aug 1, 2009, at 11:05 AM, Sam Johnston wrote: > > Bob, > > Very interesting. Are you desigining a client or an API or both? A lot of > this looks *very* similar to the current thinking around the OGF's Open > Cloud Computing Interface (OCCI), right down to the discovery document and > use of LINK elements (and HTTP Link: headers). More info at > http://www.occi-wg.org/ but be warned that the documentation currently > lags the discussions... it looks like there's a good opportunity for us to > work together here (both client libraries like libcloud and standard > interfaces like OCCI will be required). > > > > > >

2 1

Format-neutral PubSubHubbub alternatives
by Sam Johnston 06 Aug '09

06 Aug '09

Morning all, Apologies for missing the call yesterday - was unexpectedly out of range (and subsequently out of batteries). I'm on holidays but still working on OCCI - currently looking at status updates/notifications and specifically whether anyone knows of any format-neutral alternatives to PubSubHubbub<http://code.google.com/p/pubsubhubbub/> ? Sam

4 6

Reminder: OCCI weekly concall tomorrow at 4pm CET
by Thijs Metsch 05 Aug '09

05 Aug '09

Hi guys, Again it is time for our weekly concall. We'll meet tomorrow at 4pm CET. For other timezones and the details for the conference bridge visit our wiki: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… The agenda currently includes: 1. Use case and requirements document 2. draft API specification document More topics can be added here: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Concall20090… All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 1