I'll send out a [PROPOSAL] e-mail so others who may not be following this e-mail thread have a better chance to comment on the feature.
On Tue, Jun 10, 2014 at 2:58 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Here is that design document I was referring to, Punith: > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111 > > I've been working with a student in Tunisia who is participating in Google > Summer of Code (GSoC) (I'm his mentor). > > He'll be working on part of this as will I. (He is also working on another > related task not listed here.) > > Feel free to join us, if you have time available, as we can divide out > coding and testing among the three of us. > > Talk to you later! > Mike > > > On Tue, Jun 10, 2014 at 10:18 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> 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>*™* >> > > > > -- > *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>*™*
