[occi-wg] Syntax of OCCI API
eprparadocs at gmail.com
eprparadocs at gmail.com
Thu Apr 16 12:09:31 CDT 2009
I'd +1 moving back to simplified XML from INI.
Chuck Wegrzyn
Richard Davies wrote:
> Sam Johnston wrote:
>> Here's a first pass at flattening the Atom into INI file format
>> (basically what you had but with "=" for human & computer readability):
>
> Great stuff - I think this is a big step forward to be able to express
> everything as a simple list of objects, each specified by simple key-value
> pairs. Hopefully we can also similarly add a JSON version using the same
> simple data structures, e.g.:
>
> {"category":"server", "title":"Debian...", "mc.state":"running", ... }
>
>
> I've got two specific comments on the example you give:
>
>
> 1) I'm not sure INI format is actually the best text format for key-value.
> I'd prefer something easier to parse from Unix shell, which is where I
> imagine most simple scripts will be written. ElasticHosts went with
>
> "key" (without spaces), <space>, "value" (any characters including spaces)
>
> since this can be parsed with
>
> cat file | while read key value ; do ... ; done
>
>
> 2) Going through the keys and values in detail:
>
>> [decca5a5-8952-4004-9793-cdbbf05c3c63]
>
> I like UUIDs and ElasticHosts also uses them, but I might loosen the
> requirement to any unique string of hex and dashes (since other vendors may
> prefer to number sequentially, etc.)
>
>> category = server
>> title = Debian GNU/Linux 5.0 Virtual Appliance
>> summary = Base installation of Debian GNU/Linux 5.0
>
> Do we need both a title ('name' with ElasticHosts at present) and a summary
> or can we just have one of these?
>
>> content.cpu = 2
>> content.memory = 4Gb
>
> We need to agree units here! Presumably memory would be specified in 'GB' or
> alternatively 'MB', 'kB' or nothing. Is CPU the speed quota or the number of
> virtual cores? I recommend cores=<integer> and an additional key for speed
> quota (ElasticHosts uses cpu=<total MHz to divide across all cores>)
>
> Can we cut the namespace and just write:
>
> cores = 2
> cpu = 4000MHz
> mem = 4GB
>
>> link.disk[0].id = 4696b561-a253-42b4-bd27-7aa4950e0a60
>> link.disk[0].dev = sda
>> link.network[0].id = 45a73b80-c957-4ae1-97c6-b70652eba1d1
>> link.network[0].dev = eth0
>
> This is good - a mapping between hardware devices and uuids of the storage
> or network objects.
>
> We don't need the [0] indices, since the 'dev' specifiers are already fully
> unique. Taking those out and cutting the namespace gives something like:
>
> disk.sda = 4696b561-a253-42b4-bd27-7aa4950e0a60
> network.eth0 = 45a73b80-c957-4ae1-97c6-b70652eba1d1
>
>> mc.state = RUNNING
>> br.meter.rate = 0.10
>> br.meter.currency = USD
>> br.meter.unit = hours
>> br.meter.total = 35.27
>> pm.monitor.cpu = 75.2
>> pm.monitor.mem = 1059374258
>
> All look reasonable, but again I would cut the namespaces:
>
> state = RUNNING
> br.rate = 0.10
> br.currency = SD
> br.unit = hours
> br.total = 35.27
> pm.cpu = 75.2
> pm.mem = 1059374258
>
>> mc.ops.start = http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/start
>> mc.ops.stop = http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/stop
>> mc.ops.restart = http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/restart
>> mc.ops.suspend = http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/suspend
>
> Do we need these at all? Surely these will always be the operations which
> are possible on a RUNNING server, and so can always be constructed based on
> the UUID.
>
> Also, why have 'ops' in the URLs? Why not just
>
> http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/start
>
>
>> [4696b561-a253-42b4-bd27-7aa4950e0a60]
>
> I guess storage needs a 'title' (or 'name') too?
>
>> category = storage
>> content.size = 148251374
>
> Why not just 'size'?
>
>> link.self = virtual-disk.vmdk
>
> Not sure what this is?
>
>
>> [45a73b80-c957-4ae1-97c6-b70652eba1d1]
>
> Again, maybe a 'name'?
>
>> category = network
>> content.vlan = 4095
>> content.dhcp = true
>> content.subnet = 192.168.0.0
>> content.netmask = 255.255.0.0
>> content.gateway = 192.168.0.1
>
> Once again, I'd take the 'content' prefix off all of these.
>
> The keys you list here work when the network interface is on a private VLAN,
> but are the wrong set when it is on the public internet.
>
> On the public internet, the cloud vendor, not the user, defines most of
> these parameters and need to be able to control the customer VM from
> "stealing" IPs from other customers.
>
> The customer has access to a defined set of static IPs which they have
> purchased or alternatively a free dynamic IP assigned at boot, and all they
> should be able to specify is which of these they want on this particular
> interface, and whether they want to receive a DHCP for it.
>
> For instance, ElasticHosts currently specifies as:
>
> ip = <specified static IP address or 'auto' to assign dynamically at boot>
> dhcp = <ip address to send by dhcp or 'auto'; no dhcp if not present>
>
> Given that the customer will have a set of static IPs which they have
> purchased (common concept across Amazon, ElasticHosts, GoGrid, etc.), the
> API also needs an ability for them to list what these are!
>
>> av.com.cisco.cdp = true
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
More information about the occi-wg
mailing list