Hi Richard, Thanks for the comments, they are welcomed and appreciated. I'd like like to address some of your comments and changes to the storage attributes that were partially reviewed but not approved on last Wednesday's meeting. RD: - Storage: add a 'status' which is 'mounted', 'inactive', etc. GM: Storage Status has been added to the attributes. Status is define as an enumeration using terminology consistent with the storage industry. Status values currently selected include Online, Offline, Standby and Degraded. These status values reflect the disposition of the raw virtual storage device. GM: Your comments reflect another type of status that pertains to the operating system's disposition to the storage ie mounted and unmounted. I believe supporting this class of status qualifies as a step into PAAS space and significantly increases the complexity of OCCI implementations. Supporting the mounted and unmounted status values requires integration into the operating system's file system operating modes which may require additional monitoring and management technologies for each OS supported. RD: - Storage: reliability isn't the same as transient/persistent. A persistent RD: storage is one which isn't destroyed when the compute shuts down. It could RD: still be on RAID, local disk, SAN, etc. So split out 'storage.type'? which RD: is Enum(transient, persistent) from storage.reliability GM: Agreed, reliability isn't the same as durability or retention duration. I believe there is a little confusion about the compute life cycle, and the relationships and provisioning status of resources. In OCCI, storage and networking resources are bound to a compute resource. The compute resource life cycle can be describe in 3 basic abstract states, existing, not existing and operating. In the existing state, we a have a configuration provisioned and coordinated in the provider infrastructure. The nonexisting state defines relationships between resources and any provisioning as invalid. The operating state where the VM can be on, off, paused, etc. In the OCCI model, even though the compute resource is "off" it still exists and all associated resources remain provisioned. If the end user would like the storage deleted immediately after the compute resource is switch off, it may be manually deleted, if that's permissible by the provider. The retention duration attribute defines the time a storage resource will be around "after" the deletion operation is requested by the end user. The user may request the storage is kept for a while or deleted immediately. Does this meet your requirement or am I misinterpreting your request ? BTW, The OCCI spec has still not reconciled maintaining a list of provisioned resources that are not associated with a compute resource. Cheers, gary Richard Davies wrote:

I was on Wednesday's call, but here are the points that I made written out as well.

They are mostly the same as I made on 18th August in my post http://www.ogf.org/pipermail/occi-wg/2009-August/001113.html There was some discussion at that point, but not much seems to have been integrated.

Page 4-5, paragraphs 13-24 Page 8, paragraph 29

We define 3 OCCI formats in page 12, paragraph 61: text/occi, application/occi+atom, application/occi+json.

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).

Page 8, paragraph 43 Page 18, paragraph 78

I can't find any actual actions listed anywhere in this document. Are they defined yet? We need things like stop and start for servers, etc. as discussed when we used to call these verbs in a state machine.

Page 10, paragraph 52

"Where an operation returns multiple resources ..." to be replaced with "Where an operation COULD return multiple resources..."

to make it clear that a collection is always returned, even if there is a single result.

Page 10, paragraph 56-57 Page 18, paragraph 79

I'd like to see a more detail in one of these places on specifying the details of a link between compute and network - e.g. which interface does the network appear on (eth0, eth1, etc?), which static IPs are available to a customer and which will be used on this interface?

Will we specify canonical interface names for OCCI or allow each cloud to chose its own (eth0 vs. Local Area Network, etc.)?

Page 10, paragraph 56-57 Page 18, paragraph 80

Similarly, I'd like to see more detail in one of these places on specifying the details of a link between compute and storage - e.g. which interface does the storage appear on (sda, sda, etc?), which of multiple storage resources is the boot device?

Will we specify canonical interface names for OCCI or allow each cloud to chose its own (sda vs hda vs C:, etc.)?

Page 17, paragraph 76

In my use cases, I don't see much value for raw hostnames of network or storage resources. Perhaps make this optional or for compute only? Or perhaps generalize it from just a hostname to a full URL - I can imagine having some kind of web interface for directly accessing a network or storage resource?

Page 18, paragraph 78 Page 19, paragraph 80

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. - Compute: add a 'compute.type'? which is Enum(transient, persistent).

- Storage: add a 'status' which is 'mounted', 'inactive', etc. - 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

Page 19, table 7

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. To take Gary's suggestion of supporting SI suffixes.

Page 18, paragraph 78 Page 19, paragraph 80

I definitely feel that the compute.memory.speed, compute.memory.reliability and storage.reliability are less important than the other attributes described. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

Hi Richard Comments inline Richard Davies wrote:

Hi Gary,

Sorry for the time getting back. Some answers...

...

RD: - Storage: add a 'status' which is 'mounted', 'inactive', etc.

GM: Storage Status has been added to the attributes. Status is define as an enumeration using terminology consistent with the storage industry. Status values currently selected include Online, Offline, Standby and Degraded. These status values reflect the disposition of the raw virtual storage device.

Yes, and this is fine.

-

...

GM: Your comments reflect another type of status that pertains to the operating system's disposition to the storage ie mounted and unmounted. I believe supporting this class of status qualifies as a step into PAAS space and significantly increases the complexity of OCCI implementations. Supporting the mounted and unmounted status values requires integration into the operating system's file system operating modes which may require additional monitoring and management technologies for each OS supported.

I actually meant one step back from that - 'attached to a compute resource' and 'not attached to a compute resource', regardless of whether the compute resource's operating system is actually mounting the drive.

I think this is still IaaS. It's useful too - for example ElasticHosts API exposes this and we use it to prevent users attaching the same storage to multiple compute resources and accidentally corrupting their filesystems.

Agreed, I have asked for a place for provisioned resources not attached to a compute resource. This is important in cases where occi is only an interface for interchange and other provider specific interfaces will be used to provision resources, including automated policies provisioning resources on customer signup.

...

RD: - Storage: reliability isn't the same as transient/persistent. A persistent RD: storage is one which isn't destroyed when the compute shuts down. It could RD: still be on RAID, local disk, SAN, etc. So split out 'storage.type'? which RD: is Enum(transient, persistent) from storage.reliability

GM: Agreed, reliability isn't the same as durability or retention duration. I believe there is a little confusion about the compute life cycle, and the relationships and provisioning status of resources. In OCCI, storage and networking resources are bound to a compute resource. The compute resource life cycle can be describe in 3 basic abstract states, existing, not existing and operating. In the existing state, we a have a configuration provisioned and coordinated in the provider infrastructure. The nonexisting state defines relationships between resources and any provisioning as invalid. The operating state where the VM can be on, off, paused, etc. In the OCCI model, even though the compute resource is "off" it still exists and all associated resources remain provisioned. If the end user would like the storage deleted immediately after the compute resource is switch off, it may be manually deleted, if that's permissible by the provider.

The retention duration attribute defines the time a storage resource will be around "after" the deletion operation is requested by the end user. The user may request the storage is kept for a while or deleted immediately.

Yes, you are broadly correct. I am only really considering two options here: deleted immediately or left around indefinitely.

We see two very different behaviours on existing clouds when an compute's operating system is shut down internally (i.e. by a user logged into that compute resource, without any API calls being made).

Amazon: When the compute's operating system shuts down, the compute and the storage are immediately gone for ever.

GoGrid: When the compute's operating system shuts down, the compute and the storage both remain available to be restarted later.

OCCI should support both, and should do so by having a property on both compute and storage resources which specifies what will happen to them when the compute resource shuts down.

Ok got it. There is a class of storage that is tied directly to the on/off state of the VM.

Cheers,

Richard.