[GitHub] cloudstack pull request: Test fails in Widows as the file separato...

[GabrielBrascher]

GitHub user GabrielBrascher opened a pull request:

https://github.com/apache/cloudstack/pull/1498

Test fails in Widows as the file separator "/" is different from "\"

**Problem:**
File separator in windows ("\") is different from the expected in the test 
("/"); thus, the test *com.cloud.utils.SwiftUtilTest.testSplitSwiftPath()* will 
fail in Windows systems.

The problem is that the input of the test is *"container/object"* but the 
tested method uses the *File.separator* (that depends on from the OS), in the 
windows the tested method (*com.cloud.utils.SwiftUtil.splitSwiftPath(String)*) 
looks for a "\", as the string does not contain "\" it returns an empty string 
and consequently results in a test failure.

**Solution:**
- Create a string `String input = "container" + File.separator + "object";` 
(before it was `String input = "container/object";`); thus, independent of the 
OS, the test will validate the tested method in a manner that the file 
separator does not disturb the result;

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/GabrielBrascher/cloudstack lrg-cs-hackday-038

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1498.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1498


commit a83514041cd865b06bee33d2440ea42b1e7c1337
Author: gabrascher 
Date:   2016-04-16T18:35:17Z

Test fails in Widows as the file separator "/" is different from "\"

File separator in windows is different from linux (the expected in the
test); thus, the test
*com.cloud.utils.SwiftUtilTest.testSplitSwiftPath()* will fail in
windows. The problem is that the input of the test is
*"container/object"* but the tested method uses the *File.separator*
(that depends from the OS), in the windows the tested method
(*com.cloud.utils.SwiftUtil.splitSwiftPath(String)*) looks for a "\" in
windows systems, resulting in an empty string and consequently a failure
in the test.

Some solutions:
- the simple way is to create a string `String input = "container" +
File.separator + "object";`, thus independent of the OS, the test will
succeed.
- a tricky solution is to mock the final static variable
*File.separator* and return "/".

I picked the easy way.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-9322: Support for Internal LB ...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1452#issuecomment-210849171
  
started the suite now but keep in mind that no sdn specific tests are done 
in it, @swill  


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

Thanks, Adrian!

In my case, it's a dev environment, so it's not really hurting anything (it 
just seems like weird behavior, so I was curious if others were seeing it).

I can create a ticket in Jira and add your info and mine to it.

Thanks again!

> On Apr 16, 2016, at 4:43 AM, Adrian Sender  wrote:
> 
> Hi Mike,
> 
> Hi have observed this behavior on CCP 4.3.x mostly and xenserver 6.5 less so
> in 4.5.1. I use Fiber Channel LVMoHBA as the primary storage.
> 
> Seems like the same issue.
> 
> Disk Attached to Dom0 after snapshot or copy from secondary to primary:
> 
> In this example we have a disk attached to dom0, we cannot delete the disk
> until we detach it.
> 
> admin.rc.precise 0 Created by template provisioner 42 GB   Control domain on
> host cpms1-1.nsp.testlabs.com.au
> 
> [root@cpms1-1 ~]# xe vdi-list name-label="admin.rc.precise 0"
> 
> uuid ( RO): 3d79722b-294d-4358-bc57-af92b9e9dda7
> name-label ( RW): admin.rc.precise 0
>   name-description ( RW): Created by template provisioner
>sr-uuid ( RO): dce1ec02-cce0-347d-0679-f39c9ea64da1
>   virtual-size ( RO): 45097156608
>   sharable ( RO): false
>  read-only ( RO): false
> 
> You will want to list out the VBD (connector object between VM and VDI) based
> on the VDI UUID. Here is an example:
> 
> [root@cpms1-1 ~]# xe vbd-list vdi-uuid=3d79722b-294d-4358-bc57-af92b9e9dda7
> 
> uuid ( RO) : d9e2d89e-a82f-9e6e-c97a-afe0af47468e
> vm-uuid ( RO): 0f4cb186-0167-47d6-afb5-89b00102250b
>   vm-name-label ( RO): Control domain on host: cpms1-1.nsp.nectar.org.au
>vdi-uuid ( RO): 3d79722b-294d-4358-bc57-af92b9e9dda7
>   empty ( RO): false
>  device ( RO):
> 
> 
> Once done, you want to first try to make VBD inactive (it may already be
> inactive), "The device is not currently attached"
> 
> xe vbd-unplug uuid=d9e2d89e-a82f-9e6e-c97a-afe0af47468e
> 
> Once done, you can then break the connection:
> 
> xe vbd-destroy uuid=
> 
> Now you can delete the disk from xencenter
> 
> Regards,
> Adrian Sender
> 
> 
> 
> -- Original Message ---
> From: Anshul Gangwar 
> To: "dev@cloudstack.apache.org" 
> Sent: Fri, 15 Apr 2016 06:48:59 +
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic
> Zone on 4.9
> 
>> Mike, what type of storage are you using?
>> 
>>> On 15-Apr-2016, at 9:49 AM, Tutkowski, Mike  
>>> wrote:
>>> 
>>> I'm not sure, Daan.
>>> 
>>> I plan to keep an eye on this behavior for a while when creating new clouds.
>>> 
>>> 
>>> From: Daan Hoogland 
>>> Sent: Thursday, April 14, 2016 2:12 AM
>>> To: dev
>>> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>>> 
>>> Mike, did the iso copy process not complete as expected. Sound like they
>>> are a remanence of some task ending in an exception. Probably a silently
>>> ignored one ;|
>>> 
>>> On Thu, Apr 14, 2016 at 2:49 AM, Tutkowski, Mike 
>>> wrote:
>>> 
 Just an FYI, but when I kicked off my first VM in this cloud, the VR
 happened to get deployed to XenServer-6.5-3 (which was one of my XenServer
 hosts that had an un-expected shared SR pointing at secondary storage
 beforehand).
 
 Once the process of copying the system template down to local storage
 completed, the shared SR pointing at secondary storage went away (as you
 would expect).
 
 This leaves me now with one un-expected shared SR pointing at secondary
 storage on XenServer-6.5-1.
 
 
 From: Tutkowski, Mike 
 Sent: Wednesday, April 13, 2016 5:10 PM
 To: dev@cloudstack.apache.org
 Subject: Strange XenServer SR behavior when deploying system VMs in Basic
 Zone on 4.9
 
 Hi,
 
 
 Has anyone recently observed the following behavior:
 
 
 http://imgur.com/8ALJmWb
 
 
 As you can see in the image, I have three 6.5 XenServer hosts in a
 resource pool.
 
 
 I just used them when creating a basic zone and the system VMs were
 deployed just fine. However, there are SRs pointing to secondary storage on
 my XenServer-6.5-1 and XenServer-6.5-3 hosts still (there used to be one on
 my XenServer-6.5-2 host, but it went away once the system VMs started up on
 that host).
 
 
 Thoughts?
 
 
 Thanks,
 
 Mike
>>> 
>>> 
>>> 
>>> --
>>> Daan
>> 
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information 
>> which is the property of Accelerite, a Persistent Systems business. 
>> It is intended only for the use of the individual or entity to which 
>> it is addressed. If you are not the intended 

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Adrian Sender]

Hi Mike,

Hi have observed this behavior on CCP 4.3.x mostly and xenserver 6.5 less so
in 4.5.1. I use Fiber Channel LVMoHBA as the primary storage.

Seems like the same issue.

Disk Attached to Dom0 after snapshot or copy from secondary to primary:

In this example we have a disk attached to dom0, we cannot delete the disk
until we detach it.

admin.rc.precise 0 Created by template provisioner 42 GB   Control domain on
host cpms1-1.nsp.testlabs.com.au

[root@cpms1-1 ~]# xe vdi-list name-label="admin.rc.precise 0"

uuid ( RO): 3d79722b-294d-4358-bc57-af92b9e9dda7
 name-label ( RW): admin.rc.precise 0
   name-description ( RW): Created by template provisioner
sr-uuid ( RO): dce1ec02-cce0-347d-0679-f39c9ea64da1
   virtual-size ( RO): 45097156608
   sharable ( RO): false
  read-only ( RO): false

You will want to list out the VBD (connector object between VM and VDI) based
on the VDI UUID. Here is an example:

[root@cpms1-1 ~]# xe vbd-list vdi-uuid=3d79722b-294d-4358-bc57-af92b9e9dda7

uuid ( RO) : d9e2d89e-a82f-9e6e-c97a-afe0af47468e
 vm-uuid ( RO): 0f4cb186-0167-47d6-afb5-89b00102250b
   vm-name-label ( RO): Control domain on host: cpms1-1.nsp.nectar.org.au
vdi-uuid ( RO): 3d79722b-294d-4358-bc57-af92b9e9dda7
   empty ( RO): false
  device ( RO):


Once done, you want to first try to make VBD inactive (it may already be
inactive), "The device is not currently attached"

xe vbd-unplug uuid=d9e2d89e-a82f-9e6e-c97a-afe0af47468e

Once done, you can then break the connection:

xe vbd-destroy uuid=

Now you can delete the disk from xencenter

Regards,
Adrian Sender



-- Original Message ---
From: Anshul Gangwar 
To: "dev@cloudstack.apache.org" 
Sent: Fri, 15 Apr 2016 06:48:59 +
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9

> Mike, what type of storage are you using?
> 
> > On 15-Apr-2016, at 9:49 AM, Tutkowski, Mike  
> > wrote:
> > 
> > I'm not sure, Daan.
> > 
> > I plan to keep an eye on this behavior for a while when creating new clouds.
> > 
> > 
> > From: Daan Hoogland 
> > Sent: Thursday, April 14, 2016 2:12 AM
> > To: dev
> > Subject: Re: Strange XenServer SR behavior when deploying system VMs in
Basic Zone on 4.9
> > 
> > Mike, did the iso copy process not complete as expected. Sound like they
> > are a remanence of some task ending in an exception. Probably a silently
> > ignored one ;|
> > 
> > On Thu, Apr 14, 2016 at 2:49 AM, Tutkowski, Mike 
> > wrote:
> > 
> >> Just an FYI, but when I kicked off my first VM in this cloud, the VR
> >> happened to get deployed to XenServer-6.5-3 (which was one of my XenServer
> >> hosts that had an un-expected shared SR pointing at secondary storage
> >> beforehand).
> >> 
> >> Once the process of copying the system template down to local storage
> >> completed, the shared SR pointing at secondary storage went away (as you
> >> would expect).
> >> 
> >> This leaves me now with one un-expected shared SR pointing at secondary
> >> storage on XenServer-6.5-1.
> >> 
> >> 
> >> From: Tutkowski, Mike 
> >> Sent: Wednesday, April 13, 2016 5:10 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Strange XenServer SR behavior when deploying system VMs in Basic
> >> Zone on 4.9
> >> 
> >> Hi,
> >> 
> >> 
> >> Has anyone recently observed the following behavior:
> >> 
> >> 
> >> http://imgur.com/8ALJmWb
> >> 
> >> 
> >> As you can see in the image, I have three 6.5 XenServer hosts in a
> >> resource pool.
> >> 
> >> 
> >> I just used them when creating a basic zone and the system VMs were
> >> deployed just fine. However, there are SRs pointing to secondary storage on
> >> my XenServer-6.5-1 and XenServer-6.5-3 hosts still (there used to be one on
> >> my XenServer-6.5-2 host, but it went away once the system VMs started up on
> >> that host).
> >> 
> >> 
> >> Thoughts?
> >> 
> >> 
> >> Thanks,
> >> 
> >> Mike
> >> 
> > 
> > 
> > 
> > --
> > Daan
> 
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information 
> which is the property of Accelerite, a Persistent Systems business. 
> It is intended only for the use of the individual or entity to which 
> it is addressed. If you are not the intended recipient, you are not 
> authorized to read, retain, copy, print, distribute or use this 
> message. If you have received this communication in error, please 
> notify the sender and delete all copies of this message. Accelerite, 
> a Persistent Systems business does not accept any liability for 
> virus infected mails.
--- End of Original Message ---