Also, if we are good with Edison merging my code into his branch before going into master, I am good with that.
We can remove the StoragePoolType.Dynamic code after his merge and we can deal with Burst IOPS then, as well. On Mon, Jun 10, 2013 at 9:08 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Let me make sure I follow where we're going here: > > 1) There should be NO references to hypervisor code in the storage > plug-ins code (this includes the default storage plug-in, which currently > sends several commands to the hypervisor in use (although it does not know > which hypervisor (XenServer, ESX(i), etc.) is actually in use)) > > 2) managed=true or managed=false can be placed in the url field (if not > present, we default to false). This info is stored in the > storage_pool_details table. > > 3) When the "attach" command is sent to the hypervisor in question, we > pass the managed property along (this takes the place of the > StoragePoolType.Dynamic check). > > 4) execute(AttachVolumeCommand) in the hypervisor checks for the managed > property. If true for an attach, the necessary hypervisor data structure is > created and the rest of the attach command executes to attach the volume. > > 5) When execute(AttachVolumeCommand) is invoked to detach a volume, the > same check is made. If managed, the hypervisor data structure is removed. > > 6) I do not see an clear way to support Burst IOPS in 4.2 unless it is > stored in the volumes and disk_offerings table. If we have some idea, > that'd be cool. > > Thanks! > > > On Mon, Jun 10, 2013 at 8:58 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> "+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. >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
