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: S3/Swift Problem around Virtual Size
Date Wed, 10 Sep 2014 16:47:15 GMT
I have not heard recently on when code freeze for 4.5 is, per se.

Regardless, I'd say this is an important-enough issue that we should wait
for your patch.

We're still in the process of getting 4.3.1 and 4.4.1 out the door, so I
think it'll be a bit before 4.5 goes out.

Thanks for your time and effort on this, Punith!

On Wed, Sep 10, 2014 at 10:32 AM, Punith S <punith.s@cloudbyte.com> wrote:

> yes mike,
>
> i'm fixing the issue w.r.t option 2.
>
> testing the patch is consuming much time, since i have to register the
> templates via S3, and it has to download via S3 to staging store.
>
> can i know when is the code freez for 4.5 ?
>
> thanks!
>
> On Tue, Sep 9, 2014 at 9:30 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> Yeah, either solution will fix this issue for managed storage in general
>> (ex. SolidFire, CloudByte).
>>
>> On Tue, Sep 9, 2014 at 9:58 AM, Francois Gaudreault <
>> fgaudreault@cloudops.com> wrote:
>>
>>> That's great Punith :)
>>>
>>> Thanks for handling this one. I am not too worried about the option, as
>>> long as it fixes SF integration for 4.5 :)
>>>
>>> FG
>>>
>>> On Tue, Sep 9, 2014 at 11:55 AM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>>
>>>> Thanks for the info, Punith!
>>>>
>>>> Does that mean you are fixing the issue via Option2?
>>>>
>>>> On Tue, Sep 9, 2014 at 7:52 AM, Punith S <punith.s@cloudbyte.com>
>>>> wrote:
>>>>
>>>>> yes mike,
>>>>>
>>>>> w.r.t to option 1:
>>>>> it will be like creating a VM w.r.t ISO, where admin will have to
>>>>> specify the os disk(ROOT) disk size.
>>>>>
>>>>> for option 2:
>>>>> i have figured out the issue, post downloading the template to S3,
>>>>> cloudstack will again download the template from S3 to staging nfs store.
>>>>> here we need to access the file and process it with VHD processor in
>>>>> order to calculate the virtualsize but we are skipping this process,
>>>>> hence the virtual size is not being calculated while using the S3 or
>>>>> swift.
>>>>>
>>>>> the templates already present in the staging nfs storage cannot be
>>>>> applied to this process.
>>>>>
>>>>> for option 3:
>>>>> it's convenient to calculate the template virtual size while it is
>>>>> being copied from s3 to staged nfs store instead of staged nfs to primary,
>>>>> since admin might be using more than one primary stores.
>>>>>
>>>>> i'm fixing the issue, will post the patch ASAP for 4.5.snapshot.
>>>>>
>>>>> thanks!
>>>>>
>>>>> On Tue, Sep 9, 2014 at 11:13 AM, Mike Tutkowski <
>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>
>>>>>> By the way, for anyone new to this issue, this is what we're
>>>>>> referring to here:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-7406
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 11:41 PM, Mike Tutkowski <
>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>
>>>>>>> Great :) Then a question might be, "Is it too late in the game
to
>>>>>>> interrogate the template to discover its virtual size if we're
just about
>>>>>>> to copy the template to primary storage?"
>>>>>>>
>>>>>>> If it's not, this might be the place to run the logic to figure
out
>>>>>>> the virtual size.
>>>>>>>
>>>>>>> Really, there are three big possibilities:
>>>>>>>
>>>>>>> 1) Just ask the end user to provide the virtual size (not commenting
>>>>>>> here on what happens for already-uploaded templates)
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> 2) Figure out the virtual size when the template is copied from
>>>>>>> object storage to secondary storage and update the DB with this
info (not
>>>>>>> sure what happens if the template has already been copied to
>>>>>>> (secondary-storage) NFS because it was used before)
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> 3) Figure out the virtual size when the template is about to
be
>>>>>>> copied from secondary storage to primary storage
>>>>>>>
>>>>>>> On Mon, Sep 8, 2014 at 11:35 PM, Sanjeev Neelarapu <
>>>>>>> sanjeev.neelarapu@citrix.com> wrote:
>>>>>>>
>>>>>>>> Mike,
>>>>>>>>
>>>>>>>> You are right. Template gets copied to (secondary-storage)
NFS
>>>>>>>> before being copied to primary storage
>>>>>>>>
>>>>>>>> -Sanjeev
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>> Sent: Tuesday, September 09, 2014 10:55 AM
>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>> Cc: Punith S; Francois Gaudreault
>>>>>>>> Subject: Re: S3/Swift Problem around Virtual Size
>>>>>>>>
>>>>>>>> Hi Will,
>>>>>>>>
>>>>>>>> Thanks for the input!
>>>>>>>>
>>>>>>>> I like the idea of storing the virtual size as metadata in
S3 or
>>>>>>>> Swift although this could require that the end user provide
this value when
>>>>>>>> uploading the template.
>>>>>>>>
>>>>>>>> However, if we have the ability to determine the virtual
size of
>>>>>>>> the template after it gets downloaded to (secondary-storage)
NFS and we're
>>>>>>>> able to update the database with this info, then it would
seem we would
>>>>>>>> never need to ask the user for this value.
>>>>>>>>
>>>>>>>> Either way, the tricky part might be if the template in object
>>>>>>>> storage has already been downloaded to (secondary-storage)
NFS (say it was
>>>>>>>> used before). In this case, we won't need to download it
to
>>>>>>>> (secondary-storage) NFS again (at least not in the same zone),
so we won't
>>>>>>>> have an easy opportunity to figure out the virtual size upon
download from
>>>>>>>> object storage.
>>>>>>>>
>>>>>>>> I wonder if it's too late in this process if we figured out
the
>>>>>>>> virtual size before the copied template (now on (secondary-storage)
NFS)
>>>>>>>> gets copied to primary storage. If we could do it at this
point, then we
>>>>>>>> wouldn't have to worry about fixing the "legacy" situation
because it would
>>>>>>>> just work out naturally. We would look in the DB to see if
the virtual size
>>>>>>>> for this template is known and, if not, we could figure out
the virtual
>>>>>>>> size before downloading from (secondary-storage) NFS to primary
storage
>>>>>>>> each time. (Although I'm thinking this would come too late
in the process
>>>>>>>> because we may have already asked the primary-storage plug-in
to create the
>>>>>>>> necessary volume.)
>>>>>>>>
>>>>>>>> By the way, I'm assuming that a template gets copied to
>>>>>>>> (secondary-storage) NFS before being copied to primary storage.
I'm not
>>>>>>>> super familiar with how this process works.
>>>>>>>>
>>>>>>>> Talk to you later,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> On Mon, Sep 8, 2014 at 10:59 PM, Will Stevens <
>>>>>>>> wstevens@cloudops.com> wrote:
>>>>>>>>
>>>>>>>> > My two cents on the topic.
>>>>>>>> >
>>>>>>>> > Ideally we would save the size in the object store metadata
and
>>>>>>>> > retrieve it from the metadata if it is set.  If it is
not set in
>>>>>>>> the
>>>>>>>> > object store metadata, then when it is fetched, we have
to put it
>>>>>>>> on
>>>>>>>> > NFS and determine the size (then ideally save the metadata
back
>>>>>>>> to the
>>>>>>>> > object store) and remove the NFS copy.
>>>>>>>> >
>>>>>>>> > This way the NFS copy approach is only ever done once
and then the
>>>>>>>> > data is populated (for backwards compatibility).  For
all
>>>>>>>> templates
>>>>>>>> > created after the patch, the metadata would be stored
and
>>>>>>>> retrieved
>>>>>>>> > without the need for the NFS copy.
>>>>>>>> >
>>>>>>>> > Is this feasible?
>>>>>>>> >
>>>>>>>> > Will
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > *Will STEVENS*
>>>>>>>> > Lead Developer
>>>>>>>> >
>>>>>>>> > *CloudOps* *| *Cloud Solutions Experts
>>>>>>>> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com
>>>>>>>> *|* tw
>>>>>>>> > @CloudOps_
>>>>>>>> >
>>>>>>>> > On Tue, Sep 9, 2014 at 12:48 AM, Mike Tutkowski <
>>>>>>>> > mike.tutkowski@solidfire.com> wrote:
>>>>>>>> >
>>>>>>>> > > Hi Punith,
>>>>>>>> > >
>>>>>>>> > > Thanks for putting in time on this!
>>>>>>>> > >
>>>>>>>> > > So, option 1 occurs after we download the template
to S3 or
>>>>>>>> Swift.
>>>>>>>> > > We
>>>>>>>> > then
>>>>>>>> > > have to copy it to NFS so that we can determine
the virtual
>>>>>>>> size?
>>>>>>>> > > Relatively slow, but it would work.
>>>>>>>> > >
>>>>>>>> > > If we went this route, would we then delete that
template from
>>>>>>>> the
>>>>>>>> > > NFS share since its immediate purpose was so we
could figure
>>>>>>>> out the
>>>>>>>> > > virtual size or would we leave it on that share?
>>>>>>>> > >
>>>>>>>> > > Option 2 is to allow the user who uploads such
a template to
>>>>>>>> specify
>>>>>>>> > > the size needed for the root disk (i.e. at least
the virtual
>>>>>>>> size of
>>>>>>>> > > the template...perhaps larger)?
>>>>>>>> > >
>>>>>>>> > > Does that sound like I understood the options?
>>>>>>>> > >
>>>>>>>> > > Thanks!
>>>>>>>> > > Mike
>>>>>>>> > >
>>>>>>>> > > On Mon, Sep 8, 2014 at 10:34 PM, Punith S <
>>>>>>>> punith.s@cloudbyte.com>
>>>>>>>> > wrote:
>>>>>>>> > >
>>>>>>>> > > > hi mike,
>>>>>>>> > > >
>>>>>>>> > > > i have figured out the issue, in NFS secondary
storage the
>>>>>>>> virtual
>>>>>>>> > > > size
>>>>>>>> > > is
>>>>>>>> > > > been calculated by the VHD Processor by accessing
the vhd
>>>>>>>> template.
>>>>>>>> > > >
>>>>>>>> > > > but in case of S3, cloudstack is not able
to access the
>>>>>>>> template
>>>>>>>> > > > but it only gets to know the physical size
of the template!
>>>>>>>> > > >
>>>>>>>> > > > in order to solve this, we need to download
the template from
>>>>>>>> S3
>>>>>>>> > > > to another secondary nfs storage and access
the template to
>>>>>>>> > > > calculate the virtual size.
>>>>>>>> > > >
>>>>>>>> > > > if the above solution seems to be complicated,
we shall have a
>>>>>>>> > > > quick
>>>>>>>> > fix
>>>>>>>> > > > where virtual size i.e the size of the SAN
volume shall be
>>>>>>>> > > > created(like small-20g, medium-40g) for people
using the
>>>>>>>> templates from S3.
>>>>>>>> > > >
>>>>>>>> > > > any feedback's ?
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > On Tue, Sep 9, 2014 at 6:34 AM, Mike Tutkowski
<
>>>>>>>> > > > mike.tutkowski@solidfire.com> wrote:
>>>>>>>> > > >
>>>>>>>> > > >> Hi Punith,
>>>>>>>> > > >>
>>>>>>>> > > >> Have you been able to make any progress
with regards to this
>>>>>>>> > > >> Swift/S3 issue?
>>>>>>>> > > >>
>>>>>>>> > > >> Thanks!
>>>>>>>> > > >> Mike
>>>>>>>> > > >>
>>>>>>>> > > >> On Wed, Aug 27, 2014 at 7:43 AM, Punith
S
>>>>>>>> > > >> <punith.s@cloudbyte.com>
>>>>>>>> > > wrote:
>>>>>>>> > > >>
>>>>>>>> > > >> > hi
>>>>>>>> > > >> >
>>>>>>>> > > >> > think i had a timeout problem!
>>>>>>>> > > >> > on the second try the template has
been downloaded to the
>>>>>>>> S3
>>>>>>>> > > >> > bucket
>>>>>>>> > > and
>>>>>>>> > > >> > the management server shows the status
as download complete
>>>>>>>> > > >> > with
>>>>>>>> > > >> template
>>>>>>>> > > >> > size as 1.6G instead of its virtual
size 20G.
>>>>>>>> > > >> >
>>>>>>>> > > >> > and i see the template's status as
Download Complete but it
>>>>>>>> > > >> > seems it
>>>>>>>> > > is
>>>>>>>> > > >> > not getting installed ! refer the
attachment
>>>>>>>> > > >> >
>>>>>>>> > > >> > can anyone explain the "installing
template" after the
>>>>>>>> download
>>>>>>>> > > >> completes ?
>>>>>>>> > > >> >
>>>>>>>> > > >> >
>>>>>>>> > > >> > On Wed, Aug 27, 2014 at 9:18 AM,
Marcus <
>>>>>>>> shadowsor@gmail.com>
>>>>>>>> > wrote:
>>>>>>>> > > >> >
>>>>>>>> > > >> >> Per Edisons comments about not
knowing the image size,
>>>>>>>> can't
>>>>>>>> > > >> >> we
>>>>>>>> > just
>>>>>>>> > > >> set
>>>>>>>> > > >> >> some headers and store metadata
with the template in S3 to
>>>>>>>> > > >> >> save the virtual size when the
template is registered? I'm
>>>>>>>> > > >> >> assuming here that the
>>>>>>>> > SSVM
>>>>>>>> > > >> does
>>>>>>>> > > >> >> the work of pulling the template
in and uploading to S3.
>>>>>>>> Or it
>>>>>>>> > could
>>>>>>>> > > be
>>>>>>>> > > >> >> stored in the template table?
>>>>>>>> > > >> >> On Aug 26, 2014 9:11 PM, "Francois
Gaudreault" <
>>>>>>>> > > >> fgaudreault@cloudops.com>
>>>>>>>> > > >> >> wrote:
>>>>>>>> > > >> >>
>>>>>>>> > > >> >> > Looks like your SSVM cannot
reach Internet properly?
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> > FG
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> > On 2014-08-26, 11:14 AM,
Punith S wrote:
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> >> hi francois,
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> since i'm not having
a swift setup, i'm using the s3
>>>>>>>> bucket.
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> and as you recommended
i got the SSVM up with seeded
>>>>>>>> nfs
>>>>>>>> > storage,
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> post that i removed
the nfs secondary storage and
>>>>>>>> added the
>>>>>>>> > > >> >> >> S3
>>>>>>>> > > with
>>>>>>>> > > >> >> >> staging nfs store as
the new sec storage, since you
>>>>>>>> cannot
>>>>>>>> > > >> >> >> have
>>>>>>>> > > any
>>>>>>>> > > >> nfs
>>>>>>>> > > >> >> >> secondary storage while
using the S3.
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> on registering the a
new template, i'm getting template
>>>>>>>> > > >> >> >> status
>>>>>>>> > > >> >> as*Unable
>>>>>>>> > > >> >> >> to execute HTTP request:
No route to host* in
>>>>>>>> > > >> >> >> managementserver.log
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> 2014-08-26 20:41:07,502
DEBUG
>>>>>>>> [o.a.c.s.RemoteHostEndPoint]
>>>>>>>> > > >> >> >> (Timer-24:ctx-b68380cd)
Sending command
>>>>>>>> > > >> org.apache.cloudstack.storage.
>>>>>>>> > > >> >> >> command.DownloadProgressCommand
to host: 10
>>>>>>>> > > >> >> >> 2014-08-26 20:41:07,507
DEBUG [c.c.a.t.Request]
>>>>>>>> > > >> (Timer-24:ctx-b68380cd)
>>>>>>>> > > >> >> >> Seq 10-5684105679694996125:
Sending  { Cmd , MgmtId:
>>>>>>>> > 52242179434,
>>>>>>>> > > >> via:
>>>>>>>> > > >> >> >> 10(s-142-VM), Ver: v1,
Flags: 100011,
>>>>>>>> [{"org.apache.cloudstack.
>>>>>>>> > > >> >> >>
>>>>>>>> > > >>
>>>>>>>> storage.command.DownloadProgressCommand":{"jobId":"d43a17c9-3b03-
>>>>>>>> > > >> 4ff9-
>>>>>>>> > > >> >> >> 8906-e1d155981e86","request":"GET_STATUS","hvm":true,"
>>>>>>>> > > >> >> >>
>>>>>>>> > > >>
>>>>>>>> description":"centext","maxDownloadSizeInBytes":53687091200,"id":209,"
>>>>>>>> > > >> >> >>
>>>>>>>> resourceType":"TEMPLATE","installPath":"template/tmpl/2/
>>>>>>>> > > >> >> >>
>>>>>>>> 209/209-2-b624436c-5f37-30d4-8eaf-81582eb0d39d","_store":{"
>>>>>>>> > > >> >> >>
>>>>>>>> com.cloud.agent.api.to.S3TO":{"id":14,"uuid":"e4afd7bb-39ea
>>>>>>>> > > >> >> >> -
>>>>>>>> 4128-ab93-f8a09b1d5e03","bucketName":"test-cloudstack",
>>>>>>>> > > >> >> >> "httpsFlag":false,"created":"Aug
26, 2014 8:16:24
>>>>>>>> > > >> >> PM","enableRRS":false,"
>>>>>>>> > > >> >> >> maxSingleUploadSizeInBytes":5368709120}},"url":"http://
>>>>>>>> > > >> >> >>
>>>>>>>> download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz
>>>>>>>> > > >> >> >> 2
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >>
>>>>>>>> > > >>
>>>>>>>> > >
>>>>>>>> >
>>>>>>>> ","format":"VHD","accountId":2,"name":"209-2-b624436c-5f37-30d4-8eaf-8
>>>>>>>> > 1582eb0d39d","wait":0}}]
>>>>>>>> > > >> >> >> }
>>>>>>>> > > >> >> >> 2014-08-26 20:41:07,556
DEBUG [c.c.a.t.Request]
>>>>>>>> > > >> >> >> (AgentManager-Handler-10:null)
Seq
>>>>>>>> 10-5684105679694996125:
>>>>>>>> > > >> >> Processing:  {
>>>>>>>> > > >> >> >> Ans: , MgmtId: 52242179434,
via: 10, Ver: v1, Flags:
>>>>>>>> 10,
>>>>>>>> > > >> >> >> [{"com.cloud.agent.api.storage.DownloadAnswer":{"
>>>>>>>> > > >> >> >> jobId":"d43a17c9-3b03-4ff9-8906-e1d155981e86","
>>>>>>>> > > >> >> >> downloadPct":0,"errorString":"No
route to
>>>>>>>> > host","downloadStatus":"
>>>>>>>> > > >> >> >>
>>>>>>>> DOWNLOAD_ERROR","installPath":"template/tmpl/2/209/209-2-
>>>>>>>> > > >> >> >> b624436c-5f37-30d4-8eaf-81582eb0d39d","templateSize":
>>>>>>>> > > >> >> >> 0,"templatePhySicalSize":0,"result":true,"details":"No
>>>>>>>> > > >> >> >> route to host","wait":0}}]
}
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> but i don't see any
logging happening in secondary
>>>>>>>> storage
>>>>>>>> > > >> >> >> vm's
>>>>>>>> > > >> >> cloud.log
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> not sure this error
is happening due to S3!
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >> thanks!
>>>>>>>> > > >> >> >>
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> > --
>>>>>>>> > > >> >> > Francois Gaudreault
>>>>>>>> > > >> >> > Gestionnaire de Produit
| Product Manager - Cloud
>>>>>>>> Platform &
>>>>>>>> > > Services
>>>>>>>> > > >> >> > t:514-629-6775
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> > CloudOps Votre partenaire
infonuagique | Cloud Solutions
>>>>>>>> > > >> >> > Experts
>>>>>>>> > > >> >> > 420 rue Guy | Montreal |
Quebec | H3J 1S6
>>>>>>>> > > >> >> > w: cloudops.com | tw: @CloudOps_
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >> >
>>>>>>>> > > >> >>
>>>>>>>> > > >> >
>>>>>>>> > > >> >
>>>>>>>> > > >> >
>>>>>>>> > > >> > --
>>>>>>>> > > >> > 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>*™*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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>*™*

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