[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-09 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358240#comment-16358240
 ] 

ASF subversion and git services commented on CLOUDSTACK-10222:
--

Commit 94776fbfd030528feccacdfc2d1ed85a38858f3f in cloudstack's branch 
refs/heads/master from [~kmoossavi]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=94776fb ]

CLOUDSTACK-10222: Clean snaphosts from primary storage when taking new (#2398)

When user creates a snapshot (manual or recurring), snapshot remains on
the primary storage, even if the snapshot is transferred successfully to
secondary storage. This is causing issues because XenServer can only hold
a limited number of snapshots in its VDI chain, preventing the user from
creating new snapshots after some time, when too many old snapshots are
present on the primary storage.

> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.1.1
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-09 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358247#comment-16358247
 ] 

ASF subversion and git services commented on CLOUDSTACK-10222:
--

Commit 1c26b2ec2ec5f3da88b4782c365cf898cd611193 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=1c26b2e ]

Merge remote-tracking branch 'origin/4.11'

CLOUDSTACK-10269: On deletion of role set name to null (#2444)
CLOUDSTACK-10146 checksum in java instead of script (#2405)
CLOUDSTACK-10222: Clean snaphosts from primary storage when taking (#2398)

Signed-off-by: Rohit Yadav 


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.1.1
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354382#comment-16354382
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

DaanHoogland closed pull request #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/XenServerStorageProcessor.java
 
b/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/XenServerStorageProcessor.java
index 0ff2a47f481..552bc808f68 100644
--- 
a/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/XenServerStorageProcessor.java
+++ 
b/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/XenServerStorageProcessor.java
@@ -1065,7 +1065,7 @@ protected boolean 
destroySnapshotOnPrimaryStorageExceptThis(final Connection con
 return false;
 }
 
-private boolean destroySnapshotOnPrimaryStorage(final Connection conn, 
final String lastSnapshotUuid) {
+protected boolean destroySnapshotOnPrimaryStorage(final Connection conn, 
final String lastSnapshotUuid) {
 try {
 final VDI snapshot = getVDIbyUuid(conn, lastSnapshotUuid);
 if (snapshot == null) {
diff --git 
a/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 
b/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
index 6a06bef2d4b..8da7d9f6b02 100644
--- 
a/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
+++ 
b/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
@@ -559,12 +559,12 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 physicalSize = Long.parseLong(tmp[1]);
 finalPath = folder + File.separator + snapshotBackupUuid + 
".vhd";
 }
-
-final String volumeUuid = snapshotTO.getVolume().getPath();
-
-destroySnapshotOnPrimaryStorageExceptThis(conn, volumeUuid, 
snapshotUuid);
 }
 
+// remove every snapshot except this one from primary storage
+final String volumeUuid = snapshotTO.getVolume().getPath();
+destroySnapshotOnPrimaryStorageExceptThis(conn, volumeUuid, 
snapshotUuid);
+
 final SnapshotObjectTO newSnapshot = new SnapshotObjectTO();
 newSnapshot.setPath(finalPath);
 newSnapshot.setPhysicalSize(physicalSize);
@@ -577,12 +577,13 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
 return new CopyCmdAnswer(newSnapshot);
-} catch (final Types.XenAPIException e) {
-details = "BackupSnapshot Failed due to " + e.toString();
-s_logger.warn(details, e);
 } catch (final Exception e) {
-details = "BackupSnapshot Failed due to " + e.getMessage();
+final String reason = e instanceof Types.XenAPIException ? 
e.toString() : e.getMessage();
+details = "BackupSnapshot Failed due to " + reason;
 s_logger.warn(details, e);
+
+// remove last bad primary snapshot when exception happens
+destroySnapshotOnPrimaryStorage(conn, snapshotUuid);
 }
 
 return new CopyCmdAnswer(details);


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot rema

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354383#comment-16354383
 ] 

ASF subversion and git services commented on CLOUDSTACK-10222:
--

Commit 94776fbfd030528feccacdfc2d1ed85a38858f3f in cloudstack's branch 
refs/heads/4.11 from [~kmoossavi]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=94776fb ]

CLOUDSTACK-10222: Clean snaphosts from primary storage when taking new (#2398)

When user creates a snapshot (manual or recurring), snapshot remains on
the primary storage, even if the snapshot is transferred successfully to
secondary storage. This is causing issues because XenServer can only hold
a limited number of snapshots in its VDI chain, preventing the user from
creating new snapshots after some time, when too many old snapshots are
present on the primary storage.

> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354379#comment-16354379
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

DaanHoogland commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-363531208
 
 
   hm, i gues it already had. merging


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354307#comment-16354307
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-36351
 
 
   All tests passed. I already reviewed and approved the proposed changes. I 
believe we need someone else to review and approve this as well.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354308#comment-16354308
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-36351
 
 
   All tests passed. I already reviewed and approved the proposed changes. 
However, I believe we need someone else to review and approve this as well.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354246#comment-16354246
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on issue #2398: CLOUDSTACK-10222: Clean previous snaphosts 
from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-363510373
 
 
   @rhtyd @rafaelweingartner @wido @DaanHoogland Since 4.11 is out can we get 
these PR going again?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-02-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16354249#comment-16354249
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on issue #2398: CLOUDSTACK-10222: Clean previous snaphosts 
from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-363510373
 
 
   @rhtyd @rafaelweingartner @wido @DaanHoogland Since 4.11 is out can we get 
this PR going again?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-15 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326008#comment-16326008
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

mike-tutkowski commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357619686
 
 
   No, I wasn’t aware that he had done so. That’s great. :-)
   
   On Jan 14, 2018, at 9:56 PM, Khosrow Moossavi 
mailto:notificati...@github.com>> wrote:
   
   
   @mike-tutkowski Rohit already added this 
to 4.11.1 milestone, unless you meant something else.
   
   —
   You are receiving this because you were mentioned.
   Reply to this email directly, view it on 
GitHub, 
or mute the 
thread.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325901#comment-16325901
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

blueorangutan commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357586716
 
 
   Trillian test result (tid-2152)
   Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 35543 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2398-t2152-xenserver-65sp1.zip
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Smoke tests completed. 67 look OK, 0 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>Priority: Major
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325732#comment-16325732
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

blueorangutan commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357535880
 
 
   @rhtyd a Trillian-Jenkins test job (centos7 mgmt + xenserver-65sp1) has been 
kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325731#comment-16325731
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rhtyd commented on issue #2398: CLOUDSTACK-10222: Clean previous snaphosts from 
primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357535828
 
 
   @blueorangutan test centos7 xenserver-65sp1


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325729#comment-16325729
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

blueorangutan commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357534634
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1654


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325722#comment-16325722
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

blueorangutan commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357532495
 
 
   @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted 
as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-14 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325721#comment-16325721
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rhtyd commented on issue #2398: CLOUDSTACK-10222: Clean previous snaphosts from 
primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-357532471
 
 
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320536#comment-16320536
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on a change in pull request #2398: CLOUDSTACK-10222: Clean 
previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160727347
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -559,12 +559,12 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 physicalSize = Long.parseLong(tmp[1]);
 finalPath = folder + File.separator + snapshotBackupUuid + 
".vhd";
 }
-
-final String volumeUuid = snapshotTO.getVolume().getPath();
 
 Review comment:
   Yes, some secondary storage (in our case Swift) cannot take partial 
snapshots, so we noticed the issue.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320421#comment-16320421
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

sateesh-chodapuneedi commented on issue #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-356633674
 
 
   cc @anshul-gangwar @harikrishna-patnala for review


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16319968#comment-16319968
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on a change in pull request #2398: 
CLOUDSTACK-10222: Clean previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160629183
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -559,12 +559,12 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 physicalSize = Long.parseLong(tmp[1]);
 finalPath = folder + File.separator + snapshotBackupUuid + 
".vhd";
 }
-
-final String volumeUuid = snapshotTO.getVolume().getPath();
 
 Review comment:
   This is where I was getting confused. I am inspecting the code in master, 
and we were only removing other snapshots, but the last one when it was not a 
full clone. You changed so we remove all but the last one always.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318985#comment-16318985
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on issue #2398: CLOUDSTACK-10222: Clean previous snaphosts 
from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-356385233
 
 
   @rafaelweingartner updated the PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318938#comment-16318938
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on a change in pull request #2398: CLOUDSTACK-10222: Clean 
previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160494160
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 details = "BackupSnapshot Failed due to " + e.getMessage();
 s_logger.warn(details, e);
+} finally {
+if (!successful) {
 
 Review comment:
   When the two `catch` block merged together I'll move this from `finally` to 
`catch`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318935#comment-16318935
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on a change in pull request #2398: CLOUDSTACK-10222: Clean 
previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160494001
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 
 Review comment:
   Actually not, there are multiple other exceptions can be thrown which this 
block should catch them. The difference is that `Types.XenAPIException` doesn't 
have a meaningful `getMessage()` method. I'll combine them together though.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318866#comment-16318866
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on a change in pull request #2398: 
CLOUDSTACK-10222: Clean previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160486246
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 details = "BackupSnapshot Failed due to " + e.getMessage();
 s_logger.warn(details, e);
+} finally {
+if (!successful) {
 
 Review comment:
   What about removing this finally and boolean control variable? You only need 
to worry about exception cases (normal workflow is already addressed at 
567-568). So, you can do something like this in the catch block: 
   ```
   destroySnapshotOnPrimaryStorage(conn, snapshotUuid);
   ```
   
   BTW: the method `destroySnapshotOnPrimaryStorage(Conn, String)` does seem to 
need that boolean return and we also could remove its catch of `Exception`.
 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318867#comment-16318867
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on a change in pull request #2398: 
CLOUDSTACK-10222: Clean previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160485571
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 
 Review comment:
   It seems that this generic exception can be removed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

2018-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318770#comment-16318770
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow opened a new pull request #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398
 
 
   …taking new one
   
   When user creates a snapshot (manual or recurring), snapshot remains on
   the primary storage, even if the snapshot is transferred successfully to
   secondary storage. This is causing issues because XenServer can only hold
   a limited number of snapshots in its VDI chain, preventing the user from
   creating new snapshots after some time, when too many old snapshots are
   present on the primary storage.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)