On 9/19/13 5:16 AM, "SuichII, Christopher" wrote:
>John - any chance we can get your input on the original topic. Mikes
>comment was a kind of unrelated (but a completely valid topic that I'd
>like to be a part of discussing anyway!).
>
>Mike - are you planning on implementing the snapshotting
I'm not sure on a release for when I'll implement snapshot functionality.
Maybe 4.4.
On Thu, Sep 19, 2013 at 6:16 AM, SuichII, Christopher <
chris.su...@netapp.com> wrote:
> John - any chance we can get your input on the original topic. Mikes
> comment was a kind of unrelated (but a completely v
John - any chance we can get your input on the original topic. Mikes comment
was a kind of unrelated (but a completely valid topic that I'd like to be a
part of discussing anyway!).
Mike - are you planning on implementing the snapshotting methods of the storage
subsystem API anytime in the near
On 9/18/13 9:10 AM, "Darren Shepherd" wrote:
>Here's my general concern about multiple volume snapshots at once. Giving
>such a feature leads the user to believe that snapshotting multiple
>volumes
>at once will give them consistency across the volumes in the snapshot.
>This is not true, and d
umes they want to back up, then click backup once?
> >> This
> >>>> way, the storage provider is given all the volumes at once and if they
> >> have
> >>>> some way of optimizing the request based on their hardware or software,
> >>>> they c
lumes at the same time? Is it not a cleaner experience to simply
> >>>> select all the volumes they want to back up, then click backup once?
> >> This
> >>>> way, the storage provider is given all the volumes at once and if they
> >> have
> >
; compatible.
>>>>
>>>> Now, I'm also not saying that these two solutions can't co-exist. Even
>> if
>>>> we have the ability to backup multiple volumes at once, nothing is
>> stopping
>>>> users from backing them up one
o queue is a cleaner solution. If the concern is how
> users
> >> interpret what is going on in the backend, I think we can find some way
> to
> >> make that clear to them.
> >>
> >> -Chris
> >> --
> >> Chris Suich
> >> chris.su...@net
>> Data Center Platforms – Cloud Solutions
>> Citrix, Cisco & Red Hat
>>
>> On Sep 18, 2013, at 12:26 PM, Alex Huang wrote:
>>
>>> That's my read on the proposal also but, Chris, please clarify. I don't
>> think the end user will see t
he proposal also but, Chris, please clarify. I don't
> think the end user will see the change. It's an optimization for
> interfacing with the storage backend.
> >
> > --Alex
> >
> >> -Original Message-
> >> From: Marcus Sorensen [mailto:sha
ll see the change. It's an optimization for interfacing
> with the storage backend.
>
> --Alex
>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Wednesday, September 18, 2013 9:22 AM
>> To: dev@cloudstac
nt: Wednesday, September 18, 2013 9:22 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Storage Subsystem API Interface Additions
>
> Perhaps he needs to elaborate on the use case and what he means by more
> efficient. He may be referring to multiple volumes in the sen
Perhaps he needs to elaborate on the use case and what he means by
more efficient. He may be referring to multiple volumes in the sense
of snapshotting the ROOT disks for 10 different VMs.
On Wed, Sep 18, 2013 at 10:10 AM, Darren Shepherd
wrote:
> Here's my general concern about multiple volume
Here's my general concern about multiple volume snapshots at once. Giving
such a feature leads the user to believe that snapshotting multiple volumes
at once will give them consistency across the volumes in the snapshot.
This is not true, and difficult to do with many hypervisors, and typically
re
14 matches
Mail list logo
