Alexis Richardson <alexis.richardson@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.