[Capi-bof] OCCI: Getting the ball rolling with design goals

[Sam Johnston]

Morning all,

I've spent a lot of today buried in RFCs and the like with a view to
roughing up an API and getting this show on the road. Some of the design
goals below are pretty obvious (HTTP based), others less so (WebDAV
support).

My current line of thinking is around using Atom which would allow you to
point browsers, newsreaders and a myriad other existing Atom clients
directly at your cloud entry point (e.g. http://api.example.com/occi) and
get a human readable list of virtual machines back, possibly with actionable
links (e.g. start, stop, restart) and maybe even a pretty HTML interface.
FWIW virtually all of Google's APIs are GData, which is an extension of
Atom.

Anyway hopefully this small start will get the creative juices flowing -
feel free to hack away (it is a wiki after all, at least until we're
officially approved on Wednesday). In any case let me know if you think
we're on the right track, or just feel like a religious debate over e.g. the
merits of JSON over XML.

Have yourselves a good weekend,

Sam

http://wiki.cloudcommunity.org/wiki/Open_Cloud_Computing_Interface_(OCCI)<http://wiki.cloudcommunity.org/wiki/Open_Cloud_Computing_Interface_%28OCCI%29>
Overview

The Open Cloud Computing Interface (OCCI) is an API being developed by an Open
Grid Forum <http://en.wikipedia.org/wiki/Open_Grid_Forum> working group.
Design goals

   - Based on Hypertext Transfer Protocol
(HTTP)<http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol>
   - Using Representational State Transfer
(REST)<http://en.wikipedia.org/wiki/Representational_State_Transfer>(with
   HATEOAS <http://www.stucharlton.com/blog/archives/000141.html>?)
   - Requires Transport Layer Security
(TLS)<http://en.wikipedia.org/wiki/Transport_Layer_Security>for
integrity and confidentiality
   - Relies on HTTP for security (rather than signing requests which caused
   problems<http://cloudsecurity.org/2008/12/18/whats-new-in-the-amazon-cloud-security-vulnerability-in-amazon-ec2-and-simpledb-fixed-75-months-after-notification/>for
Amazon):
      - HTTP Basic access
authentication<http://en.wikipedia.org/wiki/Basic_access_authentication>
      - TLS Client certificate
authentication<http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake>
      - OAuth <http://en.wikipedia.org/wiki/OAuth>
   - Single URL entry point for trivial client configuration and support of
   multiple different APIs (e.g.
http://api.example.com/*occi*<http://api.example.com/occi>)

   - Single structured data format (e.g.
XML<http://en.wikipedia.org/wiki/XML>vs
   JSON <http://en.wikipedia.org/wiki/JSON> vs ???)
   - Sensible, transparent versioning - only one API URL for all clients
   (perhaps using HTTP content
negotiation<http://barelyenough.org/blog/2008/05/versioning-rest-web-services/>)

   - Random UUIDs
<http://en.wikipedia.org/wiki/UUID#Version_4_.28random.29>(version 4)
for internal object identification (opaque is good for security)
   e.g. {f47ac10b-58cc-*4*372-*a*567-0e02b2c3d479}
   - WebDAV <http://en.wikipedia.org/wiki/WebDAV> interface for native OS
   GUI manipulation? (e.g. drag VM from library folder to cloud to start,
   delete to stop, etc.)
      - WebDAV adds collections et al in a "standard" fashion
      - Interesting implications for getting files into and out of the cloud

   - XML <http://en.wikipedia.org/wiki/XML> responses (with XML
namespaces<http://en.wikipedia.org/wiki/XML_namespace>for
extensibility)
      - Atom <http://en.wikipedia.org/wiki/Atom_%28standard%29> and/or
      AtomPub format (for extensive client library support?) ala Google
      GData APIs <http://code.google.com/apis/gdata/>

Objects

   - *Workload*: initially virtual machines (e.g. OVF), potentially later
   applications (e.g. Ruby gem, Python egg, Java WAR/EAR)
      - Can be identified by Internet media
type<http://en.wikipedia.org/wiki/Internet_media_type>(e.g.
application/ovf+xml)
   - *Container*: initially hypervisor (e.g. Hyper-V/KVM/VMware/Xen),
   potentially later depending on workload (e.g. Java app server for Java
   WAR/EAR)

Sandbox

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title>Open Cloud Computing Interface (OCCI)</title>
  <subtitle>A virtual data center over OCCI.</subtitle>
  <link href="http://api.example.com/occi/" rel="self"/>
  <link href="http://api.example.com/"/>
  <updated>2003-12-13T18:30:02Z</updated>
  <author>
    <name>John Doe</name>
    <email>johndoe at example.com</email>
  </author>
  <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

  <entry>
    <id>tag:example.com,2008-12-31:debian-linux-appliance</id>
    <title>Debian GNU/Linux 5.0 Virtual Appliance</title>
    <summary>Base installation of Debian GNU/Linux 5.0</summary>
    <content type="application/ovf+xml">
      <Envelope xmlns="http://schemas.dmtf.org/ovf/envelope/1"
        xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" >
        <References>
          <File ovf:id="file1" ovf:href="virtual-disk.vmdk"
ovf:size="148251374"/>
          <VirtualSystem ovf:id="Debian Virtual Appliance">
            <VirtualHardwareSection ovf:transport="iso">
              <Info>4Gb, 2 CPU, 1 disk, 2 nic virtual machine</Info>
              ...
            </VirtualHardwareSection>
          </VirtualSystem>
        </References>
      </Envelope>
    </content>
    <updated>2008-12-31T23:59:59Z</updated>
  </entry>

</feed>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/capi-bof/attachments/20090328/2e39ea1f/attachment.html