"+1 -- Burst IOPS can be implemented while avoiding implementation attributes. I always wondered about the details field. I think we should beef up the description in the documentation regarding the expected format of the field. In 4.1, I noticed that the details are not returned on the createStoratePool updateStoragePool, or listStoragePool response. Why don't we return it? It seems like it would be useful for clients to be able to inspect the contents of the details field."
Not sure how this would work storing Burst IOPS here. Burst IOPS need to be variable on a Disk Offering-by-Disk Offering basis. For each Disk Offering created, you have to be able to associate unique Burst IOPS. There is a disk_offering_details table. Maybe it could go there? I'm also not sure how you would accept the Burst IOPS in the GUI if it's not stored like the Min and Max fields are in the DB.
