Re: [occi-wg] OCCI specification document
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.
Hi Richard, Thanks for your comments...added some inline questions/comments/ideas etc... @Mark do you have any ideas/suggestions regarding the storage related comments from 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.
good remark with regards to the CD images!
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
We probably should ping the guys from SNIA about this one. I cced Mark..
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.
How would you like to handle this? Add a column to the table and stating the severity?
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. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- 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
I definitely feel that the compute.memory.speed, compute.memory.reliability and storage.reliability are less important than the other attributes described.
How would you like to handle this? Add a column to the table and stating the severity?
Ideally, I'd like to make these optional extensions, not a compulsory part of OCCI. I think there'll be quite a few attributes in this category over time, which we specify but do not require.
- 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
We probably should ping the guys from SNIA about this one. I cced Mark..
Mark, To explain my point further, I'm trying to differentiate between two different semantic behaviours for cloud storage. Taking Amazon as an example: - The root filesystem (AMI image) is 'transient': when each a server starts, a clean root filesystem is created and a clean copy of the AMI image is installed. This is all deleted when the server exits. - Elastic Block Store (EBS) volumes are 'persistent'. These can be mounted from a server after it starts. They continue to exist when that server exits and can later be mounted by a different server. These are different semantic behaviours, which say nothing about the underlying storage reliability (whether it is local disk, RAIDed local disk, SAN, regularly backed up to tape, etc). Nevertheless, this 'storage type' does need to be specified on an OCCI storage resource, since it will behave differently when a server exits, and some cloud providers can provide both options. I suggest two separate attributes: storage.type for transient/persistent behaviour and storage.reliability for the nature of the underlying hardware. Similarly, OCCI compute resources will need a type of 'persistent' or 'transient'. Transient resources vanish when the server exits (like Amazon instances), whereas persistent resources become 'stopped servers' (like GoGrid). Similarly, some cloud providers will offer both types of compute resource (e.g. persistent for servers which are expected to run 24/7 except for brief periods shut down for maintenance, vs. transient for burst compute uses). Cheers, Richard.
Thijs Metsch wrote:
Hi Richard,
Thanks for your comments...added some inline questions/comments/ideas etc...
@Mark do you have any ideas/suggestions regarding the storage related comments from 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.
good remark with regards to the CD images!
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
We probably should ping the guys from SNIA about this one. I cced Mark..
I think you are talking about something beyond what the "storage" does. This is more the VMM infrastructure reuse or non-reuse of storage given to it. Thus it should be exposed by OCCI, but CDMI has no notion of it. CDMI will have the ability to "shred" the data on storage that is freed by the infrastructure, however. So when a guest is done, the data may be truly destroyed. -- mark
Hi, I think many of Richard's comments is a result of the API document lagging consensus reached in the weekly conference calls. Below is a list of Richard's comments already addressed, but not in the OCCI API document. 5. Nouns and attributes - On the topic of units MB,GB, TB, we had agreed on IEC 60027-2 as the unit of measure for values. This standard permits the use of kilo, mega, giga, etc... Requiring the support of a float type in this case, for CD images less then GB capacity, is unnecessary . Status and reporting: Richard brings up a good point. The status values are not clearly defined, in terms of life cycle state. Storage stuff: Richard again brings up a good point about storage durability. Its a broad class of service quality not a specific technology. Defining a durability definition for storage was touched on but, do not believe solid consensus was not reached. I'd like to add this as a discussion item for tomorrow's conference call. The fact that storage is RAID or mirrored, retention periods or if data is "shredded" after use should be considered part of a "back office" infrastructure and out of scope for this version of OCCI. However, I think this is the perfect opportunity take advantage of OCCI "linking" to SNIA's CDMI. -gary Mark A. Carlson wrote:
Thijs Metsch wrote:
Hi Richard,
Thanks for your comments...added some inline questions/comments/ideas etc...
@Mark do you have any ideas/suggestions regarding the storage related comments from 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.
good remark with regards to the CD images!
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
We probably should ping the guys from SNIA about this one. I cced Mark..
I think you are talking about something beyond what the "storage" does. This is more the VMM infrastructure reuse or non-reuse of storage given to it. Thus it should be exposed by OCCI, but CDMI has no notion of it.
CDMI will have the ability to "shred" the data on storage that is freed by the infrastructure, however. So when a guest is done, the data may be truly destroyed.
-- mark ------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (4)
-
Gary Mazz -
Mark A. Carlson -
Richard Davies -
Thijs Metsch