cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: feature : changing volume properties dynamically in 4.5
Date Fri, 20 Jun 2014 06:31:53 GMT
I'll define constants for the keys in PrimaryDataStoreLifeCycle.

On Friday, June 20, 2014, Mike Tutkowski <mike.tutkowski@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.tutkowski@solidfire.com
> <javascript:_e(%7B%7D,'cvml','mike.tutkowski@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.tutkowski@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.das@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.tutkowski@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.tutkowski@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.tutkowski@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 <punith.s@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.tutkowski@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 <punith.s@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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 <
>>>>>>>>>>>>>> punith.s@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.tutkowski@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.tutkowski@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 <
>>>>>>>>>>>>>>>>> punith.s@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> <javascript:_e(%7B%7D,'cvml','mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message