hi mike, now this updateStoragePool API would be really helpful to update the backend storagepool and other third party features.
question on individual CloudStack volumes is it feasible to associate resize volume and changing IOPS into one API ? if so we might need to add more intelligence in the design to make sure disk is not detached if only IOPS is being modified in the select new disk offering else disk shall be detached if both size and IOPS vary in the selected new disk offering. thanks. On Wed, Jun 25, 2014 at 2:25 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > OK, I've completed work on enabling a storage plug-in to be notified when > the size and/or IOPS of the primary storage that it represents is changed: > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c344693e48d80313270d1a972b0a3badf315567d > > This is related to the updateStoragePool API. > > I plan to switch my focus now to the resizeVolume API so that individual > CloudStack volumes (as opposed to the entire storage pool they are from) > can have not only their size, but their IOPS updated. > > > On Fri, Jun 20, 2014 at 12:31 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> I'll define constants for the keys in PrimaryDataStoreLifeCycle. >> >> >> On Friday, June 20, 2014, Mike Tutkowski <mike.tutkow...@solidfire.com> >> wrote: >> >>> In fact, we do use a hash-map approach for some KVM storage code, too. >>> >>> Let's do that here, as well. >>> >>> I'll make that change. >>> >>> Thanks >>> >>> On Friday, June 20, 2014, Mike Tutkowski <mike.tutkow...@solidfire.com> >>> wrote: >>> >>>> We do - in some places in the code - use a hash map...like what you >>>> describe. >>>> >>>> I guess the trade off there would be that the values that contain our >>>> numbers would end up being high-level objects instead of numbers (because >>>> we don't really know what future values might be). >>>> >>>> I'm OK with either approach. >>>> >>>> On Friday, June 20, 2014, Mike Tutkowski <mike.tutkow...@solidfire.com> >>>> wrote: >>>> >>>>> Unfortunately, at the time being, the updateStoragePool API (from the >>>>> public-facing API) only takes in bytes, IOPS, and storage tags...not >>>>> details (createStoragePool takes in a lot more parameters...including >>>>> details). >>>>> >>>>> So - for now at least - we're a little limited in what the new >>>>> interface method can tell storage providers about (unless we wanted to >>>>> spend time adding to the parameter list of updateStoragePool). >>>>> >>>>> On Friday, June 20, 2014, Amit Das <amit....@cloudbyte.com> wrote: >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> Is there any use case to have a more generic signature for >>>>>> updateStoragePool API ? >>>>>> >>>>>> e.g >>>>>> void updateStoragePool(StoragePool storagePool, Map<E,V> >>>>>> updateDetails); >>>>>> // not too sure of what should be E & V as of now. To start with E & >>>>>> V can be String types or Enums for better static checks. >>>>>> >>>>>> instead of below >>>>>> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long >>>>>> capacityIops); >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Amit >>>>>> *CloudByte Inc.* <http://www.cloudbyte.com/> >>>>>> >>>>>> >>>>>> On Fri, Jun 20, 2014 at 10:37 AM, Mike Tutkowski < >>>>>> mike.tutkow...@solidfire.com> wrote: >>>>>> >>>>>>> I just wanted to update those who are interested in this thread >>>>>>> about work I've done on this over the past couple days. >>>>>>> >>>>>>> This gist is that I've added a new method to the >>>>>>> PrimaryDataStoreLifeCycle interface that has the following signature >>>>>>> (this >>>>>>> code is not yet checked in): >>>>>>> >>>>>>> void updateCapacity(StoragePool storagePool, Long capacityBytes, L >>>>>>> ong capacityIops); >>>>>>> >>>>>>> This method can be invoked from StorageManagerImpl when the >>>>>>> updateStoragePool API is called. >>>>>>> >>>>>>> This gives the storage plug-in that backs the primary storage in >>>>>>> question an opportunity to update the backend storage it represents, if >>>>>>> that makes sense to do in your particular case (for example, changing >>>>>>> the >>>>>>> size and/or IOPS of a volume). >>>>>>> >>>>>>> There is a related enhancement to the resizeVolume API that I plan >>>>>>> to tackle next week. That one will be particularly useful for managed >>>>>>> storage plug-ins. >>>>>>> >>>>>>> Also, I have been collecting input on the generic key/value proposal >>>>>>> here: >>>>>>> >>>>>>> >>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111 >>>>>>> >>>>>>> That may turn into a considerable amount of work. I was initially >>>>>>> thinking it could be fit into 4.5, but it might be 4.6. >>>>>>> >>>>>>> Thanks for any feedback! >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski < >>>>>>> mike.tutkow...@solidfire.com> wrote: >>>>>>> >>>>>>>> As I think about this more, there are two situations we should >>>>>>>> cover: >>>>>>>> >>>>>>>> 1) Non-managed storage that has control over IOPS. >>>>>>>> >>>>>>>> When you invoke the createStoragePool API, you can pass in >>>>>>>> capacityIops. >>>>>>>> >>>>>>>> We should support modifying capacityIops via the updateStoragePool >>>>>>>> API. >>>>>>>> >>>>>>>> 2) Managed storage that has control over IOPS. >>>>>>>> >>>>>>>> In this environment, there is a 1:1 mapping between a SAN volume >>>>>>>> and a CloudStack volume. >>>>>>>> >>>>>>>> This is where we need to augment the resizeVolume API to accept - >>>>>>>> in a similar fashion to size - a new value for Min and/or Max IOPS. >>>>>>>> >>>>>>>> For example, a resizeVolume can be initiated by simply selecting a >>>>>>>> new Disk Offering. >>>>>>>> >>>>>>>> In this situation, the size and IOPS are part of the new Disk >>>>>>>> Offering (i.e. neither size nor IOPS can be marked as custom) and when >>>>>>>> the >>>>>>>> resize method of the storage plug-in is invoked, it will have a chance >>>>>>>> to >>>>>>>> change the size and/or IOPS. >>>>>>>> >>>>>>>> I would say we should perform a bit of analysis in the CloudStack >>>>>>>> volume logic to NOT stop resize from being invoked on the storage >>>>>>>> plug-in >>>>>>>> IF the volume size is the same, but the IOPS are different. This way >>>>>>>> the >>>>>>>> volume can be online as long as the user is only changing the IOPS of >>>>>>>> the >>>>>>>> volume. >>>>>>>> >>>>>>>> I also think it's only a problem for XenServer for the VDI to have >>>>>>>> its size changed dynamically. >>>>>>>> >>>>>>>> I plan to draw a flowchart for this soon. Once I do that I think it >>>>>>>> will be easier to talk in detail. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 12, 2014 at 12:59 PM, Mike Tutkowski < >>>>>>>> mike.tutkow...@solidfire.com> wrote: >>>>>>>> >>>>>>>>> From what I understand about the resizeVolume API, to change the >>>>>>>>> size of a given volume, you must either: >>>>>>>>> >>>>>>>>> 1) pass in a new Disk Offering (if the current Disk Offering the >>>>>>>>> volume uses does not allow for a custom size) >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> 2) pass in the ID of the volume and a new size (if the current >>>>>>>>> Disk Offering the volume uses does allow for a custom size) >>>>>>>>> >>>>>>>>> Either way, if you are shrinking the volume's size, you then have >>>>>>>>> to pass in 'true' for the 'shrinkok' parameter. >>>>>>>>> >>>>>>>>> One thing we should do is support this same concept with IOPS. At >>>>>>>>> the time being, both Min and Max IOPS can be custom (set by user) or >>>>>>>>> non >>>>>>>>> custom (set by admin). This is a direct parallel to custom size or >>>>>>>>> non-custom size. If the user is using a non-custom IOPS setting and >>>>>>>>> wants >>>>>>>>> to switch to a custom IOPS setting, he should be able to do so by >>>>>>>>> switching >>>>>>>>> to a Disk Offering with custom IOPS. Of course we should support >>>>>>>>> doing this >>>>>>>>> while the volume is attached. >>>>>>>>> >>>>>>>>> If arbitrary key/value pairs can be associated with Disk >>>>>>>>> Offerings, then you should be able to get the new key/value pairs by >>>>>>>>> switching to a new Disk Offering. We'd want to allow this to work >>>>>>>>> with the >>>>>>>>> volume in the attached state, as well. >>>>>>>>> >>>>>>>>> Perhaps we should allow this all to happen online (volume >>>>>>>>> attached) UNLESS doing what we're about to do will change the size of >>>>>>>>> the >>>>>>>>> volume. Then we can fail the OP and tell them to detach the volume and >>>>>>>>> re-run the OP. >>>>>>>>> >>>>>>>>> What are you thoughts on that? >>>>>>>>> >>>>>>>>> Also, I think volumeResize only works for data disks at the time >>>>>>>>> being. >>>>>>>>> >>>>>>>>> In my mind, volumeResize is a bit of a misnomer now. We are really >>>>>>>>> allowing the user to resize their Disk Offering now in terms of not >>>>>>>>> only >>>>>>>>> size, but IOPS, and even arbitrary key/value pairs. This is still all >>>>>>>>> done >>>>>>>>> by selecting a new Disk Offering (or - if you have a custom size or >>>>>>>>> custom >>>>>>>>> IOPS disk offering already - by passing in the ID of the volume and >>>>>>>>> the new >>>>>>>>> size and/or IOPS). >>>>>>>>> >>>>>>>>> Let's brainstorm on this a bit and see which way makes sense to go. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 12, 2014 at 9:48 AM, Punith S <punit...@cloudbyte.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> sure mike. >>>>>>>>>> >>>>>>>>>> and i have one question, >>>>>>>>>> >>>>>>>>>> which existing volume api are we gonna use for changing disk >>>>>>>>>> offerings(properties) dynamically ? >>>>>>>>>> since resize api will not allow unless the disk is detached ! >>>>>>>>>> >>>>>>>>>> thanks. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jun 12, 2014 at 11:37 AM, Mike Tutkowski < >>>>>>>>>> mike.tutkow...@solidfire.com> wrote: >>>>>>>>>> >>>>>>>>>>> Sounds good - let me give some thought as to how we should break >>>>>>>>>>> up the work. >>>>>>>>>>> >>>>>>>>>>> My GSoC student from Tunisia will be helping us, as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jun 11, 2014 at 8:34 AM, Punith S < >>>>>>>>>>> punit...@cloudbyte.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> yes it sounds good, thanks for the proposal mike, >>>>>>>>>>>> >>>>>>>>>>>> yeah right now i have implemented prototype of my proposal, >>>>>>>>>>>> since its not generic we shall implement your proposal for 4.5. >>>>>>>>>>>> on the other hand, for 4.5 i'm supporting nfs protocol and >>>>>>>>>>>> resize feature for managed storage in xenserver, now trying to >>>>>>>>>>>> implement >>>>>>>>>>>> snapshot and support root disk for vm's. >>>>>>>>>>>> and yes if we can club together, i can start working on this >>>>>>>>>>>> proposal for data disk and get the prototype ready. >>>>>>>>>>>> what do you think ? >>>>>>>>>>>> >>>>>>>>>>>> thanks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jun 11, 2014 at 3:53 AM, Mike Tutkowski < >>>>>>>>>>>> mike.tutkow...@solidfire.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 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>*™* >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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>*™* >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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>*™* >>>>> >>>>> >>>> >>>> -- >>>> *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>*™* > -- regards, punith s cloudbyte.com
