Hi Punith, Yes, that is exactly the approach I was planning on taking: enhance the resizeVolume API to allow for IOPS control and to extend what it can do with volume sizes.
Talk to you later! Mike On Wed, Jun 25, 2014 at 7:44 AM, Punith S <punit...@cloudbyte.com> wrote: > 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, L >>>>>>> ong 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 > -- *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>*™*
