cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Punith S <punit...@cloudbyte.com>
Subject Re: S3/Swift Problem around Virtual Size
Date Thu, 11 Sep 2014 14:26:46 GMT
sure mike :)

and it seems in context of managed storage we are creating the SAN volume
before downloading the template from S3 to staging store; means the SAN
volume of false size will be already created before fetching the actual
virtual size of the template !

hence i'm hitting the same issue again, saying not enough space !

so in case of S3 and Swift, shall we reserve minimum size of the SAN volume
for allowing the copy and later shall the admin resize the SAN volume to
his needs?

any thoughts ?

thanks

On Wed, Sep 10, 2014 at 10:18 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Also, of course feel free to put me down as a reviewer when you are ready
> and I can review the code shortly after.
>
> Thanks!
>
> On Wed, Sep 10, 2014 at 10:47 AM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> 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>*™*
>>
>
>
>
> --
> *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

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