Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Fri, 9 Dec 2016 20:01:58 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.13023468.1480131250000.486099.1481313718968@Atlassian.JIRA>
In-Reply-To: <JIRA.13023468.1480131250000@Atlassian.JIRA>
References: <JIRA.13023468.1480131250000@Atlassian.JIRA> <JIRA.13023468.1480131250952@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 09 Dec 2016 20:02:01 -0000


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15736202#comment-15736202 ]=20

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

Github user rhtyd commented on the issue:

    https://github.com/apache/cloudstack/pull/1749
 =20
    @blueorangutan package


> Fixes for PR 1600
> -----------------
>
>                 Key: CLOUDSTACK-9619
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-961=
9
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the defa=
ult.)=20
>          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 getSnapshotDe=
tails. In one such scenario, the source snapshot in question is coming from=
 secondary storage (when we are creating a new volume on managed storage fr=
om a snapshot of ours that=E2=80=99s on secondary storage).
> This usually =E2=80=9Cworked=E2=80=9D in the regression tests due to a bi=
t of "luck": We retrieve the ID of the snapshot (which is on secondary stor=
age) and then try to pull out its StorageVO object (which is for primary st=
orage). If you happen to have a primary storage that matches the ID (which =
is the ID of a secondary storage), then getSnapshotDetails populates its Ma=
p<String, String> with inapplicable data (that is later ignored) and you do=
n=E2=80=99t easily see a problem. However, if you don=E2=80=99t have a prim=
ary storage that matches that ID (which I didn=E2=80=99t today because I ha=
d removed that primary storage), then a NullPointerException is thrown.
> I have fixed that issue by skipping getSnapshotDetails if the source is c=
oming from secondary storage.
> While fixing that, I noticed a couple more problems:
>   We can invoke grantAccess on a snapshot that=E2=80=99s actually on seco=
ndary storage (this doesn=E2=80=99t amount to much because the VolumeServic=
eImpl ignores the call when it=E2=80=99s not for a primary-storage driver).
>   We can invoke revokeAccess on a snapshot that=E2=80=99s actually on sec=
ondary storage (this doesn=E2=80=99t amount to much because the VolumeServi=
ceImpl ignores the call when it=E2=80=99s not for a primary-storage driver)=
.
> I have corrected those issues, as well.
> I then came across one more problem:
> =C2=B7 When using a SAN snapshot and copying it to secondary storage or c=
reating a new managed-storage volume from a snapshot of ours on secondary s=
torage, we attach to the SR in the XenServer code, but detach from it in th=
e StorageSystemDataMotionStrategy code (by sending a message to the XenServ=
er 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 (with=
out 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)