cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
Date Thu, 15 Dec 2016 06:57:58 GMT

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

ASF GitHub Bot commented on CLOUDSTACK-9619:
--------------------------------------------

Github user blueorangutan commented on the issue:

    https://github.com/apache/cloudstack/pull/1749
  
    Packaging result: ✔centos6 ✔centos7 ✔debian. JID-395


> Fixes for PR 1600
> -----------------
>
>                 Key: CLOUDSTACK-9619
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.10.0.0
>         Environment: All
>            Reporter: Mike Tutkowski
>             Fix For: 4.10.0.0
>
>
> In StorageSystemDataMotionStrategy.performCopyOfVdi we call getSnapshotDetails. In one
such scenario, the source snapshot in question is coming from secondary storage (when we are
creating a new volume on managed storage from a snapshot of ours that’s on secondary storage).
> This usually “worked” in the regression tests due to a bit of "luck": We retrieve
the ID of the snapshot (which is on secondary storage) and then try to pull out its StorageVO
object (which is for primary storage). If you happen to have a primary storage that matches
the ID (which is the ID of a secondary storage), then getSnapshotDetails populates its Map<String,
String> with inapplicable data (that is later ignored) and you don’t easily see a problem.
However, if you don’t have a primary storage that matches that ID (which I didn’t today
because I had removed that primary storage), then a NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is coming from secondary
storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that’s actually on secondary storage (this
doesn’t amount to much because the VolumeServiceImpl ignores the call when it’s not for
a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that’s actually on secondary storage (this
doesn’t amount to much because the VolumeServiceImpl ignores the call when it’s not for
a primary-storage driver).
> I have corrected those issues, as well.
> I then came across one more problem:
> · When using a SAN snapshot and copying it to secondary storage or creating a new managed-storage
volume from a snapshot of ours on secondary storage, we attach to the SR in the XenServer
code, but detach from it in the StorageSystemDataMotionStrategy code (by sending a message
to the XenServer code to perform an SR detach). Since we know to detach from the SR after
the copy is done, we should detach from the SR in the XenServer code (without that code having
to be explicitly called from outside of the XenServer logic).
> I went ahead and changed that, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message