sure mike. thanks :)
On Fri, Jul 11, 2014 at 9:18 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Just an FYI that I was busy the past week working on building integration > tests for SolidFire-related functionality that's executed in CloudStack, > but I plan to get back to this resizeVolume API work today. > > > On Wed, Jun 25, 2014 at 10:27 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> 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, >>>>>>>>>> Long 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>*™* >> > > > > -- > *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
