Allow me to follow this up with more detail (with regards to what Chris and I talked about):
As you are aware, today the way you associate a Compute Offering (CO) or a Disk Offering (DO) with a Primary Storage (PS) is via storage tagging. This has some benefits and drawbacks. One benefit is being able to have some level of vendor independence from the point of view of the CO or DO. For example, if the storage tag of a DO is "Fast", then this can be satisfied by PS that describes itself as "Fast", regardless of vendor. A major drawback with the storage-tagging approach, however, is that you are not easily able to leverage vendor-specific features, which is often why you bought storage from the vendor in question to begin with. Ideally we do not want to add each vendor's features into the system as properties that can be seen by the admin regardless of whether or not the underlying storage he's actually using supports the feature in question. This coarse approach, however, was sort of business as usual when I started in with CloudStack 1.5 years ago. That being the case, when I added QoS options to CS, I did so in a way where the admin would see Min IOPS and Max IOPS options regardless of whether or not his storage actually supported those controls (to mitigate this a bit in the GUI, the admin has to explicitly select "Storage QoS" from a combobox). We leverage the same use model with Hypervisor QoS: The admin sees these options regardless of whether or not they actually apply on the hypervisor where the VM gets deployed. Going forward, we want to implement a more fine-grain and generic approach. We would like to have a storage provider field for the CO and DO windows (this equates to the name of one and only one storage provider). If the admin inputs a specific storage provider and does not use the storage tags field, he can enter in an arbitrary number of key/value pairs in another text field (perhaps we would provide a nice entry dialog to make this easier in the GUI). These key value pairs can be passed into the storage driver when it's asked to create (or update) a volume and the storage driver can decide what each and every key/value pair means. What do you think about this approach? Thanks On Mon, Jun 9, 2014 at 1:14 PM, Mike Tutkowski <mike.tutkow...@solidfire.com > wrote: > Hi Punith, > > This kind of a feature is something Chris Suich and I discussed a while > back. > > We talked about leveraging arbitrary key/value pairs to make this happen > (OpenStack does something similar). The key/value pairs would be vendor > specific. > > If we take a key/value approach, we might be able to make this all work > the way things work today when the user wants to change an existing Compute > Offering and/or Disk Offering. > > For example, the user would pick a new Compute Offering (with presumably > has different key/value pairs) and CloudStack could inform the applicable > storage provider, who could update the volume in question. > > This way we don't need to introduce a new API command and the use model > for the user doesn't really change. > > What are you thoughts on this? > > Thanks, > Mike > > > On Mon, Jun 9, 2014 at 8:08 AM, Punith S <punit...@cloudbyte.com> wrote: > >> hi guys, >> >> since most of the third party storage providers have been implementing >> 1:1 mapping(managed storage) between a volume(dataset) and a vm >> disk(vdi/vmdk) for guaranteeing the Qos, i would like to propose a new >> feature to dynamically change the volume properties supported by storage >> vendors such as IOPS, Deduplication, Compression, Grace, Syncronization, >> Latency etc, depending on properties and features supported by respective >> storage vendors. hence providing more flexibility for users. >> >> in case of using default cloudstack storage provider, we can change the >> properties of the vdi/vmdk files apart from resizing the volume(vdi/vmdk). >> >> changes in management server include, >> >> new async web api ChangeVolumePropertiesCmd, >> new method in VolumeApiService for vo and dao validation implementations. >> new method in VolumeServiceManager for supporting callback and calling >> the respective storage provider driver's implementation. >> new method in PrimaryDataStoreDriver interface for implementing >> respective features according to their storage product. >> >> changes in UI include, >> new changing volume properties widget in volume section, showing >> different properties depending upon listed storage providers. >> >> any suggestions and feedbacks ? >> >> thanks >> >> -- >> regards, >> >> punith s >> cloudbyte.com >> > > > > -- > *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>*™*
