hi mike, thanks for the reply, i like your approach which is a very generic way and also we only need to do a few changes to the current cloudstack,
but on the other hand we are tying every property of the vendor to a disk offering through key/value pairs, since we offer lot of properties like i mentioned, this can create a lot of permutation combinations of disk offerings, for say if i need to turn deduplication On for a specific volume , should i have to create a new disk offering having current properties with deduplication On? is this approach already implemented in the current master ? and also like you mentioned about exposing a new api, is it okay if i expose our own api in my util by extending the PlugableService like in network plugins ? thanks. On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > 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>*™* > -- regards, punith s cloudbyte.com
