[occi-wg] Syntax of OCCI API

[Chris Webb]

Alexis Richardson <alexis.richardson at gmail.com> writes:

> I think it would be useful to see some more examples of design pattern
> B so that consumers who own use cases can understand your claims
> better.  Putting these in an area of the wiki, where they can be
> reviewed and edited, makes sense.

Great, I'm happy to do this. Just as a toy example, here's me creating a
real virtual machine via our API on my phone:

  POST /guests/create HTTP/1.0
  Authorization: XXX
  Accept: text/plain
  Content-type: text/plain

  cpu 1000
  smp 2
  mem 512
  ide:0:0 bac889bf-bac1-47fe-b307-104b74054b8c
  nic:0:dhcp auto

That's it---nothing more to do! The machine is created and booted and I'm
logged into it now. Speaking personally as an infrastructure user, this
ease-of-use is what I'm looking for above all else, which is why I
prioritised it. (After all infrastructure services are conceptually
trivial---just virtual machines with block devices and networking. Why
should they be complicated to use?)

> Do you think design patterns A and B are in strict conflict?  I.e. do
> we need to achieve consensus on A vs B?  And if so then is this an
> important early goal in your view?

The syntaxes are in strict conflict, but that both can support identical
semantics, i.e. an identical set of operation "verbs" on object "nouns".

I suggest that the first goal is to agree the semantics, e.g. do servers
have multiple drives, are stopped servers visible in the api, are network
interfaces or static IPs or both objects in the API, etc., then move on to
how we transmit these operations.

> * You cite ElasticHosts and GoGrid as best practice relative to your
> assumptions.  In the same context, please can you provide an exegesis
> of the SUN API?

Sure. The syntax is less unpleasant and opaque than it might have been
because they've used JSON rather XML, but the data structures are still far
too deep and complex and don't map nicely to the real hardware that
infrastructure services are supposed to be simulating. (As a user, I don't
want to know how a cloud is implemented, but I do want to know what
interface (ide primary master, virtio, scsi, or whatever) a block device
will appear on when I specify it in my VM description.)

I also note that they've created a special command line tool to access this
API. If the API is too unpleasant to use directly from shell and has to be
given an alternative interface to be usable, why not just offer nice
syntax in the first place?

Cheers,

Chris.