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 > <javascript:_e(%7B%7D,'cvml','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, 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 > <javascript:_e(%7B%7D,'cvml','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>*™*
