I plan to draw up a design document surrounding generic key/value pairs today.
Perhaps you can take a look at it when you have time, Punith? On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Hi Punith, > > Yeah, I hear you about the number of permutations involved. > > Traditionally Compute and Disk Offerings have been immutable. It makes it > easier from an accounting point of view for chargeback and billing. > > You should definitely feel free to extend the CloudStack API. I think > NetApp did this for one of their storage features in the recent past. This > way vendor-specific capabilities can be more easily offered without making > it look like all vendors support those particular features. > > I do not yet have any code in master related to generic keys/values. I'm > still designing this. > > How does your schedule look for the 4.5 release? Do you think you might > have available cycles to help out with this generic key/value > implementation? > > Talk to you later! > Mike > > > On Tue, Jun 10, 2014 at 7:09 AM, Punith S <punit...@cloudbyte.com> wrote: > >> 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 >> > > > > -- > *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>*™*
