> functionality exactly the way it was originally implemented and if
>>>>> a user wished to change the functionality they could via a global config
>>>>> variable.
>>>>>
>>>>> Your original spec for PR 2081 in confluence states that the PR
From: Tutkowski, Mike
Sent: Saturday, May 19, 2018 8:40 PM
To: dev@cloudstack.apache.org
Subject: Re: Snapshots only on Primary Storage feature
Perhaps instead of renaming the setting, we can note in its description the
hypervisors it currently pertains to.
> On
he create template or download template features are used, use the
> primary storage as the source.
>
> Kind regards,
> Glen Baars
>
> -Original Message-
> From: Will Stevens
> Sent: Saturday, 19 May 2018 12:57 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Snap
@cloudstack.apache.org
Subject: Re: Snapshots only on Primary Storage feature
I think reverting the change in 4.11.1 is probably a good idea.
*Will Stevens*
Chief Technology Officer
c 514.826.0190
<https://goo.gl/NYZ8KK>
On Fri, May 18, 2018 at 2:52 PM ilya musayev
wrote:
> Perhaps brin
which can result in the job timeout and the User may
> > assume
> > > > > that it is already Backed up based on its state, unless it is
> > > documented.
> > > > >
> > > > > -Suresh
> > > > >
> > > > > On Fri, May 18, 201
the original PR was to optionally disable this
> > > > functionality.
> > > >
> > > > We don't expose views of the backup state to our customers (we have
> our
> > > > own customer interfaces) and it's a large waste of space for us to be
>
>
>
>
> From: Will Stevens
> Sent: Friday, May 18, 2018 6:12 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Snapshots only on Primary Storage feature
>
> Just because it does not work for VMware should not a reason to rip out the
> func
be
> > backing up tons of VM images when we have a solid primary storage
> > infrastructure that already has lots of resiliency.
> >
> >
> > I guess we're going to have to revisit this again before we can consider
> > rebasing on 4.11.
> >
> > ___
ons of VM images when we have a solid primary storage
> > infrastructure that already has lots of resiliency.
> >
> >
> > I guess we're going to have to revisit this again before we can consider
> > rebasing on 4.11.
> >
> > _____
up image was copied on demand to secondary.
> >
> > In an ideal world, secondary storage wouldn't even be involved in most of
> > these options, instead using the native clone features of the underlying
> > storage.
> >
> >
> > - Si
> >
> > ___
;
> - Si
>
>
> From: Suresh Kumar Anaparti
> Sent: Thursday, May 17, 2018 1:37 PM
> To: dev@cloudstack.apache.org
> Cc: Nathan Johnson
> Subject: Re: Snapshots only on Primary Storage feature
>
> Hi Glen / Si,
>
> In PR# 1697, t
ouldn't even be involved in most of
> > these options, instead using the native clone features of the underlying
> > storage.
> >
> >
> > - Si
> >
> > ________________
> > From: Suresh Kumar Anaparti
> > Sent: Thursda
;
>
> From: Suresh Kumar Anaparti
> Sent: Thursday, May 17, 2018 1:37 PM
> To: dev@cloudstack.apache.org
> Cc: Nathan Johnson
> Subject: Re: Snapshots only on Primary Storage feature
>
> Hi Glen / Si,
>
> In PR# 1697, the global setting *sna
1:37 PM
To: dev@cloudstack.apache.org
Cc: Nathan Johnson
Subject: Re: Snapshots only on Primary Storage feature
Hi Glen / Si,
In PR# 1697, the global setting *snapshot.backup.rightafter* if set to
true, it'll be the default behaviour and snapshot is copied to the
secondary storage. If set to fals
Hi Glen / Si,
In PR# 1697, the global setting *snapshot.backup.rightafter* if set to
true, it'll be the default behaviour and snapshot is copied to the
secondary storage. If set to false, then the snapshot state transitions are
mocked and Snapshot would be in BackedUp state even though it is not r
Glen,
This feature was implemented in 4.9 by my colleague Nathan Johnson. You enable
it by changing the global setting snapshot.backup.rightafter to false.
The PR is reference here: https://github.com/apache/cloudstack/pull/1697
We have the exact same use case as you, as we also use Ceph.
16 matches
Mail list logo
