Re: Review Request 27017: CLOUDSTACK-6282: Added newly automated tests and also modified some existing tests to remove dependency
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27017/#review62786 --- Ship it! Ship It! - Alex Brett On Nov. 3, 2014, 6:19 a.m., Vinay Varma wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27017/ --- (Updated Nov. 3, 2014, 6:19 a.m.) Review request for cloudstack, Alex Brett and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282: Added newly automated tests and also modified some existing tests to remove dependency Diffs - test/integration/component/test_escalations_instances.py 1aaa688 test/integration/component/test_escalations_snapshots.py 4b6b7f5 test/integration/component/test_escalations_templates.py 78028bc test/integration/component/test_escalations_volumes.py 7290325 test/integration/component/test_escalations_vpncustomergateways.py b09930a tools/marvin/marvin/cloudstackTestClient.py ce7ffc9 tools/marvin/marvin/lib/base.py 77faeeb tools/marvin/marvin/lib/utils.py b58b59d Diff: https://reviews.apache.org/r/27017/diff/ Testing --- Attached are the results files for each of the file modified and the results shows everything is fine File Attachments Instancesresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/6ea95260-f31e-4fdd-a9f3-f30bac872df5__Instancesresults.txt Snapshotsresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/a91e862c-dc2e-403e-85e4-6479eefcd9d1__Snapshotsresults.txt Templatesresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/545fd06e-4975-4330-8390-3723d944ec2b__Templatesresults.txt Voumesresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/9932b16c-684f-41ce-b6f9-192fe887c2b8__Voumesresults.txt VPNCustomerGatewaysresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/58c5f08e-cac7-4873-a922-8c874a9a8e3a__VPNCustomerGatewaysresults.txt Thanks, Vinay Varma
Re: Review Request 27017: CLOUDSTACK-6282: Added newly automated tests and also modified some existing tests to remove dependency
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27017/#review59327 --- test/integration/component/test_escalations_instances.py https://reviews.apache.org/r/27017/#comment100591 Is this supposed to be commented out (in which case it should probably just be removed), or is this leftover from debugging? test/integration/component/test_escalations_instances.py https://reviews.apache.org/r/27017/#comment100592 It might be better to put this function in Marvin as a library function for other tests? test/integration/component/test_escalations_snapshots.py https://reviews.apache.org/r/27017/#comment100593 This looks almost identical to the previous one (other than obviously grabbing memory), would it be worth having these methods call a shared method with just a parameter as to whether to include memory or not, to avoid code duplication? (The risk is someone fixes a bug in one, but not the other or whatever) - Alex Brett On Oct. 31, 2014, 4:37 a.m., Vinay Varma wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27017/ --- (Updated Oct. 31, 2014, 4:37 a.m.) Review request for cloudstack, Alex Brett and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282: Added newly automated tests and also modified some existing tests to remove dependency Diffs - test/integration/component/test_escalations_instances.py 1aaa688 test/integration/component/test_escalations_snapshots.py 4b6b7f5 test/integration/component/test_escalations_templates.py 78028bc test/integration/component/test_escalations_volumes.py 7290325 test/integration/component/test_escalations_vpncustomergateways.py b09930a tools/marvin/marvin/cloudstackTestClient.py ce7ffc9 tools/marvin/marvin/lib/base.py 77faeeb Diff: https://reviews.apache.org/r/27017/diff/ Testing --- Attached are the results files for each of the file modified and the results shows everything is fine File Attachments Instancesresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/6ea95260-f31e-4fdd-a9f3-f30bac872df5__Instancesresults.txt Snapshotsresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/a91e862c-dc2e-403e-85e4-6479eefcd9d1__Snapshotsresults.txt Templatesresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/545fd06e-4975-4330-8390-3723d944ec2b__Templatesresults.txt Voumesresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/9932b16c-684f-41ce-b6f9-192fe887c2b8__Voumesresults.txt VPNCustomerGatewaysresults.txt https://reviews.apache.org/media/uploaded/files/2014/10/22/58c5f08e-cac7-4873-a922-8c874a9a8e3a__VPNCustomerGatewaysresults.txt Thanks, Vinay Varma
Review Request 26760: Skip various BVT tests on LXC
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26760/ --- Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7727 https://issues.apache.org/jira/browse/CLOUDSTACK-7727 Repository: cloudstack-git Description --- A number of BVT tests are not valid for LXC (e.g. migrating a VM), so this patch ensures they skip if LXC is in use. LXC restrictions taken from https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Enhancements Diffs - test/integration/smoke/test_primary_storage.py 0813d28 test/integration/smoke/test_scale_vm.py 0b770c4 test/integration/smoke/test_snapshots.py 5db3e40 test/integration/smoke/test_templates.py db938d9 test/integration/smoke/test_vm_life_cycle.py 0be518d test/integration/smoke/test_vm_snapshots.py dae945c Diff: https://reviews.apache.org/r/26760/diff/ Testing --- Run all changed files against LXC and ensured appropriate tests skipped. Thanks, Alex Brett
Re: Review Request 25266: Simulator build support need to extends for RPM build
On Oct. 8, 2014, 5:07 p.m., Frank Zhang wrote:
Ship It!
Unfortunately what's actually been pushed in
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f96c65416a2802bcf2a1f8d5a5070ffe6a29111f
is missing a rather crucial change - in package.sh while it now takes the
simulator argument, it doesn't actually pass it on to the rpmbuild command,
i.e. this part of the diff has been missed:
```
-(cd $RPMDIR; rpmbuild --define _topdir $RPMDIR ${DEFVER} ${DEFREL}
${DEFPRE+${DEFPRE}} ${DEFOSSNOSS+$DEFOSSNOSS} ${DOS} -bb SPECS/cloud.spec)
+(cd $RPMDIR; rpmbuild --define _topdir $RPMDIR ${DEFVER} ${DEFREL}
${DEFPRE+${DEFPRE}} ${DEFOSSNOSS+$DEFOSSNOSS} ${DEFSIM+$DEFSIM} ${DOS}
-bb SPECS/cloud.spec)
```
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25266/#review55820
---
On Sept. 19, 2014, 7:17 p.m., Rayees Namathponnan wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25266/
---
(Updated Sept. 19, 2014, 7:17 p.m.)
Review request for cloudstack, Frank Zhang and Hugo Trippaers.
Bugs: CLOUDSTACK-7469
https://issues.apache.org/jira/browse/CLOUDSTACK-7469
Repository: cloudstack-git
Description
---
Currently there is no option to build rpm with simulator, as part this patch
modified package.sh file to accept simulator
also updated cloud.spec file to build both oss and nooss simulator buids
To build noredist and simulator, you need to use below package command
./package.sh --pack noredist --s simulator
default package with simulato, need to call ./package.sh
Diffs
-
packaging/centos63/cloud.spec 7306d1f
packaging/centos63/package.sh 6a2d168
Diff: https://reviews.apache.org/r/25266/diff/
Testing
---
Yes
File Attachments
0001-Simulator-build-support-for-RPM-builds.patch
https://reviews.apache.org/media/uploaded/files/2014/09/19/2537284e-f1de-419a-b5b6-66b8ddfcac84__0001-Simulator-build-support-for-RPM-builds.patch
Thanks,
Rayees Namathponnan
Review Request 26364: CLOUDSTACK-7673 Handle multiple gateways in test_ssvm.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26364/ --- Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7673 https://issues.apache.org/jira/browse/CLOUDSTACK-7673 Repository: cloudstack-git Description --- In some situations (e.g. EIP) listVlanRanges can return multiple entries, however the checks in test_ssvm.py were only ever looking at the first result, therefore these tests could incorrectly fail. Modify the check to look at all returned gateways for a match Diffs - test/integration/smoke/test_ssvm.py 5713569 Diff: https://reviews.apache.org/r/26364/diff/ Testing --- Verified the tests pass in a normal scenario Thanks, Alex Brett
RE: Shellshock
On 03 October 2014 13:52, Adrian Lewis [adr...@alsiconsulting.co.uk] wrote: The only solution I can think of is to 'apt-get update bash' on every system VM but clearly these get fired up dynamically. Is it possible to boot the template, make modifications and then use as a replacement system VM? Are there processes that happen on boot that only happen once and therefore need resetting to recreate the template? This isn't a quick fix, so not suitable for this specific issue, but something I've wondered for a while is rather than keep having to build new system VM templates for every small change, would we be better integrating a tool such as Puppet / Chef, so we can bring a system VM 'up to date' when it boots, as long as it's the right 'base'. What I'm thinking here (using Puppet terminology as that's what I'm familiar with, but could be any similar mechanism or even just a simple script) is when the system VM loads up, it connects to the management server and retrieves a manifest, which it then applies. That manifest would specify: - Packages to update (including if necessary any apt/yum repo information) - Config files to put in place - Anything else required like starting any services etc While it would slightly delay the boot process, it would ensure that on e.g. upgrade, you don't have to immediately replace your system VM template unless a substantial change (e.g. base system VM distro / partition layout) has been made. You could still bring in an updated template to speed things up, but it would be far less urgent to do so... Any thoughts on this anybody? Alex
Re: Review Request 24882: CLOUDSTACK-6282 - Added skip condition when hypervisor is hyper-v for tests which are not applicable for hyper-v
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24882/#review54798 --- test/integration/component/test_escalations_instances.py https://reviews.apache.org/r/24882/#comment95069 Minor one but where we're checking multiple hypervisors to skip I'd have done e.g. if self.hypervisor.lower() in ['kvm', 'hyperv']: or similar rather than have two separate ifs... test/integration/component/test_escalations_isos.py https://reviews.apache.org/r/24882/#comment95074 You don't need this as you've already got above: from marvin.lib.utils import * - Alex Brett On Sept. 29, 2014, 7:13 a.m., Vinay Varma wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24882/ --- (Updated Sept. 29, 2014, 7:13 a.m.) Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282 - Added skip condition when hypervisor is hyper-v for tests which are not applicable for hyper-v Diffs - test/integration/component/test_escalations_instances.py 73ebf13 test/integration/component/test_escalations_ipaddresses.py b29cd1d test/integration/component/test_escalations_isos.py 925c2fb test/integration/component/test_escalations_networks.py c0ab709 test/integration/component/test_escalations_snapshots.py 8d289e1 test/integration/component/test_escalations_volumes.py 8d6ba99 Diff: https://reviews.apache.org/r/24882/diff/ Testing --- Executed the tests and attached are the log files for each of the files changed. File Attachments InstancesResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/4ac84a27-fc7c-4b8c-9509-d75a350b53a3__InstancesResults.txt IPAddressesResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/14aad713-9256-44ed-a9e2-d7225c5c975c__IPAddressesResults.txt IsoResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/516de1c8-09d0-4e07-abe4-3483463750c3__IsoResults.txt SnapshotsResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/46f2a6c3-f0f7-4397-918e-bb8df1d63e97__SnapshotsResults.txt VolumeResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/28d59100-315b-45e8-9aaa-b60982571637__VolumeResults.txt NetworksResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/869b26e2-9fc2-44cf-bbc1-fc13fd60bc58__NetworksResults.txt Thanks, Vinay Varma
[BLOCKED] Management server not starting
The management server is not starting on current master builds - apparently due to a DB error. https://issues.apache.org/jira/browse/CLOUDSTACK-7621 has been filed for this, CCing Pierre-Luc Dion as the author of some DB schema changes that are potential candidates for causing the problem... Alex
RE: Marvin test cleanup
I like the idea. What worries me is the possibility to run test cases on a life system. I think it is useful for some operators to be able to do that. Those people must not lose any objects that were created outside of the test suite. Therefore it can be very tricky, not very different from your parallel use-case, though. I'd only be looking to remove objects created by the specific test case, so that should be fine. If it ended up deleting other objects it would as you say break the parallel use case so I definitely won't be looking to do that. I'll make a start on this over the next few days and see what I can get working... Alex
RE: [DISCUSS] How xs-tools gets installed for xen vms and systemvms
On essentially any current Linux distro, xs-tools doesn't actually install any drivers (in the days of RHEL4 and the like it used to have custom kernels as the vendor ones had severe limitations), because as you say the kernel has the support built in (PVops). What xs-tools gives in Linux is: - Reporting of the VM distro etc back to the toolstack - In guest memory usage reporting back to the toolstack - Installs some userspace xenstore tools The XenServer toolstack does gate some VM operations on the presence of the tools, in particular migrate. This is somewhat historical (as the tools aren't doing any driver changes they don't actually affect whether the migrate would succeed or not, but when different kernels were required the presence of the agent gave an indication the correct kernel was in use, and it is shared code with Windows guests where you do need the drivers to migrate safely), and may be changed in future, but for now is a limitation. In terms of versions, we should ideally always install one from the latest XenServer release, these should (though I'll need to do some tests to be 100% sure) work on older ones as well with no problems. Older ones will likely work properly on newer versions as well, though it will in some cases cause an out of date warning to appear in XenCenter, which could be worrying for users. Alex From: Pierre-Luc Dion [pd...@cloudops.com] Sent: 09 September 2014 17:59 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] How xs-tools gets installed for xen vms and systemvms Hi Ian, you are probably right about the PV driver of Debian 7, I can't confirmed. But, the xs-tools also provide interesting ressources usage metrics of VMs in XenServer. I think it is also required for xenmotion of VMs for maintenance purposes.
Marvin test cleanup
Hello all, At the moment we have a lot of Marvin tests that follow a pattern that looks roughly like this: 1. Setup some resources (e.g. accounts, service offerings, VMs etc) 2. Add the resources to a list in the testcase (often called self.cleanup) 3. Do the test(s) 4. Call cleanup_resources with the list of resources from 2 (obviously in some cases resources get created/allocated during the actual test rather than in setup, but it's a similar principle) In theory this is fine, however there are a number of cases where resources are being created and then not added to the cleanup list, which results in things being 'left behind', potentially using up resources which may then affect future tests. For example I'm currently attempting to run various tests in parallel (to speed up execution), and I'm hitting some issues I believe to be caused by this. The thought that occurs to me here is do we actually need the testcase to have to manually add resources to a list to cleanup, with the inherent risk of resources getting missed etc - could we not make this something the framework does for us (at least by default, with the option to override the behaviour if needed). I've got some ideas as to how this could be done (one example that's a bit of a layer violation but might be acceptable would be to wrap/extend the apiClient to have a method that can be called on it from the various object create methods to add the resulting object for cleanup), but before I go ahead and start trying to prototype something I wanted to see if anybody had any reasons why this sort of automatic cleanup behaviour might be a bad idea or has investigated anything similar in the past? Cheers, Alex
RE: test case tagging and travis output
On 04 September 2014 15:14, Daan Hoogland [daan.hoogl...@gmail.com] wrote: It seems that CLOUDSTACK-6914 introduced some new tagging scheme for test and I am assuming the new tagging should exclude the test from the travis run (makes sense and trying now). The new tagging scheme is not documented in the bug in spite of Alex Brett asking for it, so once again: @anyone: is this described somewhere? I'm not sure what exactly you're trying to achieve, but I've found what was done in CLOUDSTACK-6914 is limited as to what it can do - I've got a couple of reviews outstanding that could be relevant here which are: CLOUDSTACK-7307 / https://reviews.apache.org/r/24552/ CLOUDSTACK-7322 / https://reviews.apache.org/r/24605/ Feel free to take a look and see if you agree with what they're trying to do... Cheers, Alex
Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version
On Sept. 3, 2014, 9:32 a.m., Rajani Karuturi wrote: client/tomcatconf/classpath.conf.in, line 37 https://reviews.apache.org/r/25289/diff/1/?file=674877#file674877line37 Can we get the JAVA_HOME from installed java instead of hardcoding it? The path may be different for different os versions or distributions. something similar to what we already did at https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c468228fe807c621decc5919dadae9bcbb38c753 May we should move this to a common file like setenv.sh and use it everywhere. Frank Zhang wrote: +1 Rayees Namathponnan wrote: Hi Rajani, I checked your change list, if your machine in running with default java version is 1.6, this will always return 1.6 and management server will fails to start Even usage sever will be an issue in 4.5, if your machine is runnign with java1.6 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=packaging/centos63/cloud-usage.rc;h=8434e4d568a066d0766d055847725b1779eb33c4;hp=617037995755024a8c9d5e492bb56b7cc938e48f;hb=c468228fe807c621decc5919dadae9bcbb38c753;hpb=75c9a20c7773c268c02fb006d1a7820cb427c94c Regards, Rayees To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and Java 7 installed, the default behaviour with the alternatives mechanism makes 1.6 the default Java instance (you can manually set 1.7 as the default, but this is an extra step). This means that the management server / KVM agent then fail to work. In 6.5 if you have both then by default Java 7 is used, and all works fine (not sure about 6.4 or 7, I've not tested them). - Alex --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25289/#review52151 --- On Sept. 3, 2014, 6:25 a.m., Rayees Namathponnan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25289/ --- (Updated Sept. 3, 2014, 6:25 a.m.) Review request for cloudstack, Frank Zhang and Hugo Trippaers. Bugs: CLOUDSTACK-7474 https://issues.apache.org/jira/browse/CLOUDSTACK-7474 Repository: cloudstack-git Description --- Step 1: Deploy new RHEL 6.3 machine Step 2 : Install MS Step 3: run deploy script and start MS Result Installation completed successfully, both java7 and java got installed as part of MS installation, but MS failed to start java version erro we need to load java7 while start MS Diffs - client/tomcatconf/classpath.conf.in 3ae0fb4 Diff: https://reviews.apache.org/r/25289/diff/ Testing --- Yes Thanks, Rayees Namathponnan
Re: Review Request 24882: CLOUDSTACK-6282 - Added skip condition when hypervisor is hyper-v for tests which are not applicable for hyper-v
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24882/#review52262 --- test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/24882/#comment91028 Is there a reason for making this change - getHypervisorInfo is generally what is used elsewhere rather than the hypervisor property of services? (getHypervisorInfo has the benefit that if we ever need to start testing mixed clouds we can make sure it returns the type we want this particular test to run on, rather than the single value in services) test/integration/component/test_escalations_isos.py https://reviews.apache.org/r/24882/#comment91030 I don't see anything from cloudstackException or SshClient being used in this file - any reason to add imports for them? test/integration/component/test_escalations_isos.py https://reviews.apache.org/r/24882/#comment91027 Other things in the file use PASS from marvin.codes so this should still be imported. test/integration/component/test_escalations_isos.py https://reviews.apache.org/r/24882/#comment91026 This will break unless you change the existing usages of time.sleep to just sleep (personally I'd leave it as import time though). test/integration/component/test_escalations_isos.py https://reviews.apache.org/r/24882/#comment91031 Not your bug, but the wording here is poor - should probably be Not enough zones exist to copy iso or similar. - Alex Brett On Aug. 20, 2014, 4:22 a.m., Vinay Varma wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24882/ --- (Updated Aug. 20, 2014, 4:22 a.m.) Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282 - Added skip condition when hypervisor is hyper-v for tests which are not applicable for hyper-v Diffs - test/integration/component/test_escalations_instances.py 1b72b2f test/integration/component/test_escalations_ipaddresses.py 6c9b24b test/integration/component/test_escalations_isos.py a0fa333 test/integration/component/test_escalations_networks.py 56f61b4 test/integration/component/test_escalations_snapshots.py af493a1 test/integration/component/test_escalations_volumes.py d1dae12 Diff: https://reviews.apache.org/r/24882/diff/ Testing --- Executed the tests and attached are the log files for each of the files changed. File Attachments InstancesResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/4ac84a27-fc7c-4b8c-9509-d75a350b53a3__InstancesResults.txt IPAddressesResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/14aad713-9256-44ed-a9e2-d7225c5c975c__IPAddressesResults.txt IsoResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/516de1c8-09d0-4e07-abe4-3483463750c3__IsoResults.txt SnapshotsResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/46f2a6c3-f0f7-4397-918e-bb8df1d63e97__SnapshotsResults.txt VolumeResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/28d59100-315b-45e8-9aaa-b60982571637__VolumeResults.txt NetworksResults.txt https://reviews.apache.org/media/uploaded/files/2014/08/20/869b26e2-9fc2-44cf-bbc1-fc13fd60bc58__NetworksResults.txt Thanks, Vinay Varma
RE: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version
On 04 September 2014 00:45, David Nalley [da...@gnsa.us] wrote: On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett alex.br...@citrix.com wrote: To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and Java 7 installed, the default behaviour with the alternatives mechanism makes 1.6 the default Java instance (you can manually set 1.7 as the default, but this is an extra step). This means that the management server / KVM agent then fail to work. In 6.5 if you have both then by default Java 7 is used, and all works fine (not sure about 6.4 or 7, I've not tested them). Perhaps we add a Conflicts with java 1.6 - it would be somewhat ugly, and if you run into it you would need to know to yum remove, but that would keep you from having an installation at all rather than expecting it to work and trying to debug. I'd have thought this would prove problematic over upgrade - as you'd have a conflict that the new version would need to have 1.6 removed, but you can't do that without removing your old version first. There's also the issue of if the user wants to have both around for other tools they're running on the same machine. Some solutions that don't break upgrade that I can see are: * Rayees change in the review to point directly at Java 7, with the caveat that this might have some cross platform issues * Somehow automating the alternatives mechanism, i.e. doing a check as part of management server startup somewhere that if the default Java is 1.6, setting it to be Java 7 (which we know should be installed by the RPM dependencies) - a little ugly as we are changing a user's default underneath them, and may also have cross platform issues * Require use of 6.5 (or possibly 6.4 if the version that has works) instead of 6.3 - we do already say to install all hotfixes etc, which in theory means people should be there (yum update / upgrade on a 6.3 system will make it 6.5+), though I think we know in practise a lot of users aren't as they prefer to keep things at a stable state or only apply very specific updates. I guess this would be done by specifying a minimum Java version required that is only in the appropriate release or later. * Don't actually block it in the RPM, but check in the init script what version of Java we're going to end up picking up, and if it's 1.6 fail with a clear error message suggesting the user changes the default - still means the management server / agent won't start after upgrade, but is at least a reasonably easy fix. Alex
Review Request 25258: Fix TestVolumes.test_07_resize_fail
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25258/ --- Review request for cloudstack and Mike Tutkowski. Bugs: CLOUDSTACK-7467 https://issues.apache.org/jira/browse/CLOUDSTACK-7467 Repository: cloudstack-git Description --- Previously if you had a volume using a non customisable disk offering, and attempted to resize it passing in the same disk offering id, the command would be accepted, but it would actually be resized to its current size (i.e. the provided size parameter was ignored). This is what the test used to check. Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32 modified the logic to check if the provided diskofferingid was the same as the current one, and if so treat it as if it hadn't been provided - this means the resize command now fails, which is probably the more sensible thing to do (rather than giving the impression it will be resized but actually not doing so). This change therefore modifies the test logic to match. Diffs - test/integration/smoke/test_volumes.py e2e0d76 Diff: https://reviews.apache.org/r/25258/diff/ Testing --- Test passed running against current build Thanks, Alex Brett
RE: [BLOCKED] Unable to connect to management server on current master builds
This is still failing for me, but I think I've now found the exception that is actually showing the problem - it was hiding in localhost.date.log. I've pasted it on the ticket, but here it is as well: Aug 30, 2014 11:10:50 PM org.apache.catalina.core.StandardContext listenerStart SEVERE: Exception sending context initialized event to listener instance of class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener java.lang.NullPointerException at java.util.ArrayList.addAll(ArrayList.java:530) at com.cloud.api.auth.APIAuthenticationManagerImpl.getCommands(APIAuthenticationManagerImpl.java:72) at com.cloud.api.auth.APIAuthenticationManagerImpl.start(APIAuthenticationManagerImpl.java:56) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$1.with(CloudStackExtendedLifeCycle.java:75) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.startBeans(CloudStackExtendedLifeCycle.java:72) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycleStart.run(CloudStackExtendedLifeCycleStart.java:46) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$1.with(DefaultModuleDefinitionSet.java:105) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.startContexts(DefaultModuleDefinitionSet.java:97) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:80) at org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37) at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70) at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:57) at org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:61) at org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:593) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) Alex
RE: [BLOCKED] Unable to connect to management server on current master builds
Firstly just to confirm your workaround seems to have done the trick - I can now contact the management server again. Interestingly I don't see the log message your change added in APIAuthenticationManagerImpl.java if that means anything In terms of Java versions, at runtime I'm using whatever the 1.7 JRE you get with RHEL 6.3 is - the build will be using whatever JDK http://jenkins.buildacloud.org/job/package-rhel63-master/ uses, as that's where I've been getting the ACS master builds from. I don't have access to that Jenkins instance beyond the public access to know what it's actually running etc. Alex -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 31 August 2014 18:43 To: dev@cloudstack.apache.org Cc: Alex Brett Subject: Re: [BLOCKED] Unable to connect to management server on current master builds On 31-Aug-2014, at 5:07 pm, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Mostly Alex should be using java 1.7 only. I would advise to only use jdk 1.7 and try again with a clean environment with latest master. If it's failing for some reason check if any spring config/xmls were changed, it looks like a failed dependency injection which is causing it. Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and- build// CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack- infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack- training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [BLOCKED] Unable to connect to management server on current master builds
Logs on the CLOUDSTACK ticket below. The issue is that freshly installed management servers don't get to the stage if accepting API calls or presenting the UI - the startup just seems to stall... Aled From: Rohit Yadav [rohit.ya...@shapeblue.com] Sent: 30 August 2014 11:16 To: Min Chen Cc: dev@cloudstack.apache.org Subject: Re: [BLOCKED] Unable to connect to management server on current master builds Works for me, I’ll check the issue soon. Can Alex or anyone else facing the issue sharing logs etc? If you were to use the APIs directly, what is the exception or issue observed? On 30-Aug-2014, at 3:03 am, Min Chen min.c...@citrix.com wrote: CC Rohit here in case he didn't see this email. Rohit, can you fix this? Thanks -min On 8/29/14 9:21 AM, Alex Brett alex.br...@citrix.com wrote: Hello all, On current master builds (such as http://jenkins.buildacloud.org/job/package-rhel63-master/3202/), I can't connect to the management server, either via the API or UI. The major changes since the last working build I had seems to be the SAML2 merge (there are a couple of other things, but looking at those commits there doesn't appear to be much chance of them being the cause of the problem), so the SAML2 code would be where my suspicion lies. I've filed https://issues.apache.org/jira/browse/CLOUDSTACK-7455 for this with a log etc, but if someone familiar with the code (Rohit?) would mind looking at this and seeing if they could reproduce/fix, that would be good! Thanks, Alex Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [BLOCKED] Unable to connect to management server on current master builds
Also I note the last few simulator runs on jenkins.buildacloud.org are failing, the most recent with a SAML unit test failure... Alex From: Alex Brett [alex.br...@citrix.com] Sent: 30 August 2014 12:39 To: dev@cloudstack.apache.org; Min Chen Subject: RE: [BLOCKED] Unable to connect to management server on current master builds Logs on the CLOUDSTACK ticket below. The issue is that freshly installed management servers don't get to the stage if accepting API calls or presenting the UI - the startup just seems to stall... Aled From: Rohit Yadav [rohit.ya...@shapeblue.com] Sent: 30 August 2014 11:16 To: Min Chen Cc: dev@cloudstack.apache.org Subject: Re: [BLOCKED] Unable to connect to management server on current master builds Works for me, I’ll check the issue soon. Can Alex or anyone else facing the issue sharing logs etc? If you were to use the APIs directly, what is the exception or issue observed? On 30-Aug-2014, at 3:03 am, Min Chen min.c...@citrix.com wrote: CC Rohit here in case he didn't see this email. Rohit, can you fix this? Thanks -min On 8/29/14 9:21 AM, Alex Brett alex.br...@citrix.com wrote: Hello all, On current master builds (such as http://jenkins.buildacloud.org/job/package-rhel63-master/3202/), I can't connect to the management server, either via the API or UI. The major changes since the last working build I had seems to be the SAML2 merge (there are a couple of other things, but looking at those commits there doesn't appear to be much chance of them being the cause of the problem), so the SAML2 code would be where my suspicion lies. I've filed https://issues.apache.org/jira/browse/CLOUDSTACK-7455 for this with a log etc, but if someone familiar with the code (Rohit?) would mind looking at this and seeing if they could reproduce/fix, that would be good! Thanks, Alex Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [BLOCKED] Unable to connect to management server on current master builds
The job is http://jenkins.buildacloud.org/view/simulator/job/simulator-singlerun/239/ - I'm out the office today but in theory a BVT run should happen automatically so I'll try and check it later... Alex From: Rohit Yadav [rohit.ya...@shapeblue.com] Sent: 30 August 2014 13:36 To: dev Subject: Re: [BLOCKED] Unable to connect to management server on current master builds Alex, On 30-Aug-2014, at 1:45 pm, Alex Brett alex.br...@citrix.com wrote: Also I note the last few simulator runs on jenkins.buildacloud.org are failing, the most recent with a SAML unit test failure… Current build works for me, along with all unit tests. Can you share a link to the build job where SAML unit tests are failing? While I’m not sure what is causing the issue for you, I’ve pushed a minor fix on master that may cause a NPE for some cases and that irrespective of whether saml plugin is enabled the component return true on start(). Try if it works for you now. Alex From: Alex Brett [alex.br...@citrix.com] Sent: 30 August 2014 12:39 To: dev@cloudstack.apache.org; Min Chen Subject: RE: [BLOCKED] Unable to connect to management server on current master builds Logs on the CLOUDSTACK ticket below. The issue is that freshly installed management servers don't get to the stage if accepting API calls or presenting the UI - the startup just seems to stall... Aled From: Rohit Yadav [rohit.ya...@shapeblue.com] Sent: 30 August 2014 11:16 To: Min Chen Cc: dev@cloudstack.apache.org Subject: Re: [BLOCKED] Unable to connect to management server on current master builds Works for me, I’ll check the issue soon. Can Alex or anyone else facing the issue sharing logs etc? If you were to use the APIs directly, what is the exception or issue observed? On 30-Aug-2014, at 3:03 am, Min Chen min.c...@citrix.com wrote: CC Rohit here in case he didn't see this email. Rohit, can you fix this? Thanks -min On 8/29/14 9:21 AM, Alex Brett alex.br...@citrix.com wrote: Hello all, On current master builds (such as http://jenkins.buildacloud.org/job/package-rhel63-master/3202/), I can't connect to the management server, either via the API or UI. The major changes since the last working build I had seems to be the SAML2 merge (there are a couple of other things, but looking at those commits there doesn't appear to be much chance of them being the cause of the problem), so the SAML2 code would be where my suspicion lies. I've filed https://issues.apache.org/jira/browse/CLOUDSTACK-7455 for this with a log etc, but if someone familiar with the code (Rohit?) would mind looking at this and seeing if they could reproduce/fix, that would be good! Thanks, Alex Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp
Review Request 25187: test_delete_account and test_releaseIP failing in advanced zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25187/ --- Review request for cloudstack, Ashutosh Kelkar and Santhosh Edukulla. Bugs: CLOUDSTACK-7448 https://issues.apache.org/jira/browse/CLOUDSTACK-7448 Repository: cloudstack-git Description --- CLOUDSTACK-4840 changed test_data.py to make the lbrule publicport be 22, instead of . In doing so, this caused the following tests to fail, as they hit a problem where they tried to use port 22 for both the lbrule and for other purposes: integration.smoke.test_network.TestDeleteAccount.test_delete_account integration.smoke.test_network.TestReleaseIP.test_releaseIP The reason the change appears to have been made was that in test_lb_secondary_ip.py, despite setting up the load balancer using lbrule, the tests then used the SSH port from natrule to try and access the VM. By changing lbrule to use port 22 (the same as natrule) this avoided the problem. This patch updates test_lb_secondary_ip.py to use the SSH port in lbrule where necessary to access the VMs, and reverts the change to test_data.py Diffs - test/integration/component/test_lb_secondary_ip.py f54caa6 tools/marvin/marvin/config/test_data.py fca2442 Diff: https://reviews.apache.org/r/25187/diff/ Testing --- Ran tests in test_lb_secondary_ip.py with changes in place, verified results equivalent to those seen on regular regression runs. Ran test_delete_account and test_releaseIP to verify these now pass as expected. Thanks, Alex Brett
Unable to connect to management server on current master builds
Hello all, On current master builds (such as http://jenkins.buildacloud.org/job/package-rhel63-master/3202/), I can't connect to the management server, either via the API or UI. The major changes since the last working build I had seems to be the SAML2 merge (there are a couple of other things, but looking at those commits there doesn't appear to be much chance of them being the cause of the problem), so the SAML2 code would be where my suspicion lies. I've filed https://issues.apache.org/jira/browse/CLOUDSTACK-7455 for this with a log etc, but if someone familiar with the code (Rohit?) would mind looking at this and seeing if they could reproduce/fix, that would be good! Thanks, Alex
Review Request 24805: CLOUDSTACK-7363 test_vmware_drs.py should skip on non-VMWare hypervisors
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24805/ --- Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-7363 https://issues.apache.org/jira/browse/CLOUDSTACK-7363 Repository: cloudstack-git Description --- test_vmware_drs.py currently runs against any hypervisor, when it should only run against VMWare. This patch adds a check in setUpClass as to the hypervisor test, and will skip if VMWare is not in use. Diffs - test/integration/component/test_vmware_drs.py 7d3ab7f Diff: https://reviews.apache.org/r/24805/diff/ Testing --- Tested against a XenServer cloud, and test correctly skipped. Thanks, Alex Brett
Re: Review Request 24550: CLOUDSTACK-7306 Don't run test_01_primary_storage_iscsi on KVM or HyperV
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24550/ --- (Updated Aug. 13, 2014, 10:36 a.m.) Review request for cloudstack and Santhosh Edukulla. Changes --- Updated patch that applies to current master following some other changes made in the same file... Bugs: CLOUDSTACK-7306 https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Repository: cloudstack-git Description --- test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. Diffs (updated) - test/integration/smoke/test_primary_storage.py d2d5b4f Diff: https://reviews.apache.org/r/24550/diff/ Testing --- Ran test against KVM host to verify it skips correctly Thanks, Alex Brett
Re: Review Request 24550: CLOUDSTACK-7306 Don't run test_01_primary_storage_iscsi on KVM or HyperV
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24550/ --- (Updated Aug. 13, 2014, 10:44 a.m.) Review request for cloudstack and Santhosh Edukulla. Changes --- Additional update which removes a duplicated self.hypervisor declaration. Bugs: CLOUDSTACK-7306 https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Repository: cloudstack-git Description --- test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. Diffs (updated) - test/integration/smoke/test_primary_storage.py d2d5b4f Diff: https://reviews.apache.org/r/24550/diff/ Testing --- Ran test against KVM host to verify it skips correctly Thanks, Alex Brett
Re: Review Request 24550: CLOUDSTACK-7306 Don't run test_01_primary_storage_iscsi on KVM or HyperV
On Aug. 13, 2014, 10:43 a.m., Santhosh Edukulla wrote: test/integration/smoke/test_primary_storage.py, line 158 https://reviews.apache.org/r/24550/diff/2/?file=659231#file659231line158 This check is not required right? As well, i just pushed a similar change to master, post the ci failure. Please check. Your change unfortunately was broken in that it was put into the *NFS* test (which is supported on KVM), not the iSCSI test, which isn't. The most recent diff r4 I've done I believe resolves all of this... - Alex --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24550/#review50441 --- On Aug. 13, 2014, 10:44 a.m., Alex Brett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24550/ --- (Updated Aug. 13, 2014, 10:44 a.m.) Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-7306 https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Repository: cloudstack-git Description --- test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. Diffs - test/integration/smoke/test_primary_storage.py d2d5b4f Diff: https://reviews.apache.org/r/24550/diff/ Testing --- Ran test against KVM host to verify it skips correctly Thanks, Alex Brett
Versions on Jira and web
Hello, I'm not sure who has the power to change this, but in the Apache Jira the versions for the CLOUDSTACK project are a bit out of sync with reality - we currently incorrectly list the following as unreleased: 4.1.1 4.2.1 4.3.0 4.4.0 Also, on the downloads page (http://cloudstack.apache.org/downloads.html) we have 4.4.0, which is correct, however on the linked archives page (http://cloudstack.apache.org/archives.html) we don't seem to have 4.3.0, the newest release shown is 4.2.1 - have we accidentally lost 4.3.0 when releasing 4.4.0? Kind Regards, Alex Brett
Review Request 24605: CLOUDSTACK-7322 Tag disruptive tests
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24605/ --- Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-7322 https://issues.apache.org/jira/browse/CLOUDSTACK-7322 Repository: cloudstack-git Description --- Some tests are disruptive (in that they cannot be run in parallel with other tests, as they do disruptive things such as stopping the secondary storage VM). This patch adds a disruptive nosetests attribute to those tests which are known to be so, such that they can be easily excluded from parallel runs. Diffs - test/integration/component/maint/test_bugs.py 07e3655 test/integration/component/maint/test_egress_rules_host_maintenance.py a27ada3 test/integration/component/maint/test_high_availability.py cc687f8 test/integration/component/maint/test_multiple_ip_ranges.py 982dd7c test/integration/component/maint/test_vpc_host_maintenance.py 83ba271 test/integration/component/maint/test_vpc_on_host_maintenance.py eb3360a test/integration/smoke/test_ssvm.py 5713569 Diff: https://reviews.apache.org/r/24605/diff/ Testing --- Verified using --collect-only option to nosetests that filtering using the disruptive attribute works correctly. Thanks, Alex Brett
Review Request 24550: CLOUDSTACK-7306 Don't run test_01_primary_storage_iscsi on KVM or HyperV
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24550/ --- Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-7306 https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Repository: cloudstack-git Description --- test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 Diff: https://reviews.apache.org/r/24550/diff/ Testing --- Ran test against KVM host to verify it skips correctly Thanks, Alex Brett
Review Request 24552: CLOUDSTACK-7307 Add simulator_only attribute to tests which need it
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24552/ --- Review request for cloudstack, Gaurav Aradhye and Santhosh Edukulla. Bugs: CLOUDSTACK-7307 https://issues.apache.org/jira/browse/CLOUDSTACK-7307 Repository: cloudstack-git Description --- See full explanation and justification of this patch on the ticket at https://issues.apache.org/jira/browse/CLOUDSTACK-7307 A brief summary is that a number of tests require the simulator (e.g. to check the behaviour in a failure condition). The existing attempt at solving this issue involved setting the required_hardware attribute to simulator only, however this is not very easy to use with the nosetests runner due to limitations it has around handling attributes. By adding a new attribute (simulator_only), we can simply add !simulator_only to an attribute listing to avoid running these tests. Diffs - test/integration/smoke/misc/test_deploy_vm.py 071d15d test/integration/smoke/misc/test_vm_ha.py 601354e test/integration/smoke/test_vm_sync.py 6d56945 Diff: https://reviews.apache.org/r/24552/diff/ Testing --- Verified that tests are picked up when run without the new attribute, and not picked up when used with !simulator_only in the nosetests -a attribute list. Thanks, Alex Brett
Review Request 24050: CLOUDSTACK-7173 Make getNewMinIops and getNewMaxIops return Longs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24050/ --- Review request for cloudstack. Bugs: CLOUDSTACK-7173 https://issues.apache.org/jira/browse/CLOUDSTACK-7173 Repository: cloudstack-git Description --- The functions getNewMinIops and getNewMaxIops were returning long primitives, this can throw a NPE as the underlying Long objects could be null, which was causing volume resizes to fail. The only place this getter is called is expecting a Long object, so changing it to return a Long rather than long should be safe. Diffs - server/src/com/cloud/storage/VmWorkResizeVolume.java 1caab10 Diff: https://reviews.apache.org/r/24050/diff/ Testing --- Verified cloudstack still builds Thanks, Alex Brett
RE: Failed add KVM agent to CS with latest master
I am unable to add KVM agent with latest master build, this issue is tracked in https://issues.apache.org/jira/browse/CLOUDSTACK-7170 Those made changes in master yesterday/today, can you please check it regressed from you commit or not ? As noted on the ticket I've narrowed this down to one of the following three changesets: commit 3b32732459730bfd4848678c95c27e2eb653cc04 Author: Min Chen min.c...@citrix.com Date: Tue Jul 22 09:47:27 2014 -0700 CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid. commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3 Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Tue Jul 22 17:43:49 2014 +0200 Fix NPE reported on IRC, provide the user an informative error message commit 4523490d44160b054de9e943f72db1d0ce06054a Author: Santhosh Edukulla santhosh.eduku...@gmail.com Date: Mon Jul 21 20:49:03 2014 +0530 Fixed Coverity Issues reported Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com Alex
Review Request 22512: CLOUDSTACK-6862 Don't run vGPU tests on KVM or in the BVTs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22512/ --- Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-6862 and CLOUDSTACK-6876 https://issues.apache.org/jira/browse/CLOUDSTACK-6862 https://issues.apache.org/jira/browse/CLOUDSTACK-6876 Repository: cloudstack-git Description --- - Make this test skip if it's not running on a XenServer host (as that's the only hypervisor that supports vGPU at present) - Also remove the tags that make this test run on a BVT, since it will *only* work if run on a host with vGPU hardware See also CLOUDSTACK-6876 - I don't have rights to duplicate these two issues, but I believe they are the same thing. Diffs - test/integration/smoke/test_deploy_vgpu_enabled_vm.py fa33bdc Diff: https://reviews.apache.org/r/22512/diff/ Testing --- Tested against a KVM host to ensure the skip logic kicks in. Thanks, Alex Brett
Re: Review Request 22512: CLOUDSTACK-6862 Don't run vGPU tests on KVM or in the BVTs
On June 12, 2014, 3:27 p.m., Santhosh Edukulla wrote: test/integration/smoke/test_deploy_vgpu_enabled_vm.py, line 126 https://reviews.apache.org/r/22512/diff/1/?file=608112#file608112line126 If this is specific to entire module, then its better we move this check to setup class instead and skip. Which module are you referring to - there isn't a specific vGPU module in Marvin as far as I can see, the test just creates a ServiceOffering for VGPU with 'pciDevice': 'VGPU' set? On June 12, 2014, 3:27 p.m., Santhosh Edukulla wrote: test/integration/smoke/test_deploy_vgpu_enabled_vm.py, line 164 https://reviews.apache.org/r/22512/diff/1/?file=608112#file608112line164 Dont we require other advanced, basic,provisioning tags? Otherwise it may run on non required setups as well. As I understand it (which is quite liable to be wrong) the tags are OR'd together, there's no way of specifying that a specific attribute *must* be provided for the test to run. Only options here therefore are: 1. Ensure the BVTs (and any other run of Marvin tests that's not on VGPU hardware) have a !vgpu tag specified 2. Have a separate set of vgpu-advanced, vgpu-basic etc tags - Alex --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22512/#review45503 --- On June 12, 2014, 1:27 p.m., Alex Brett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22512/ --- (Updated June 12, 2014, 1:27 p.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-6862 and CLOUDSTACK-6876 https://issues.apache.org/jira/browse/CLOUDSTACK-6862 https://issues.apache.org/jira/browse/CLOUDSTACK-6876 Repository: cloudstack-git Description --- - Make this test skip if it's not running on a XenServer host (as that's the only hypervisor that supports vGPU at present) - Also remove the tags that make this test run on a BVT, since it will *only* work if run on a host with vGPU hardware See also CLOUDSTACK-6876 - I don't have rights to duplicate these two issues, but I believe they are the same thing. Diffs - test/integration/smoke/test_deploy_vgpu_enabled_vm.py fa33bdc Diff: https://reviews.apache.org/r/22512/diff/ Testing --- Tested against a KVM host to ensure the skip logic kicks in. Thanks, Alex Brett
Re: Review Request 22512: CLOUDSTACK-6862 Don't run vGPU tests on KVM or in the BVTs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22512/ --- (Updated June 12, 2014, 5:21 p.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Changes --- Updated patch to fix the first issue Bugs: CLOUDSTACK-6862 and CLOUDSTACK-6876 https://issues.apache.org/jira/browse/CLOUDSTACK-6862 https://issues.apache.org/jira/browse/CLOUDSTACK-6876 Repository: cloudstack-git Description --- - Make this test skip if it's not running on a XenServer host (as that's the only hypervisor that supports vGPU at present) - Also remove the tags that make this test run on a BVT, since it will *only* work if run on a host with vGPU hardware See also CLOUDSTACK-6876 - I don't have rights to duplicate these two issues, but I believe they are the same thing. Diffs (updated) - test/integration/smoke/test_deploy_vgpu_enabled_vm.py fa33bdc Diff: https://reviews.apache.org/r/22512/diff/ Testing --- Tested against a KVM host to ensure the skip logic kicks in. Thanks, Alex Brett
Re: Review Request 22512: CLOUDSTACK-6862 Don't run vGPU tests on KVM or in the BVTs
On June 12, 2014, 3:56 p.m., Santhosh Edukulla wrote: test/integration/smoke/test_deploy_vgpu_enabled_vm.py, line 164 https://reviews.apache.org/r/22512/diff/1/?file=608112#file608112line164 We have to get nose tests discovery for that. We dont have a case for vgpu. EX: A tag of advanced,means we want all advanced zone test cases, then this test case will as well be picked up otherwise wont if not tagged. Similarly, we can do and or with tags values provided separately. Sorry I don't quite follow you - this test is running in the BVTs at the moment because it is being picked up by the 'basic' and 'advanced' tags, but as there's no vGPU hardware in use it would never work. I suppose we could modify the test to skip if it's not running on vGPU hardware, but that's quite difficult to detect... - Alex --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22512/#review45510 --- On June 12, 2014, 5:21 p.m., Alex Brett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22512/ --- (Updated June 12, 2014, 5:21 p.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-6862 and CLOUDSTACK-6876 https://issues.apache.org/jira/browse/CLOUDSTACK-6862 https://issues.apache.org/jira/browse/CLOUDSTACK-6876 Repository: cloudstack-git Description --- - Make this test skip if it's not running on a XenServer host (as that's the only hypervisor that supports vGPU at present) - Also remove the tags that make this test run on a BVT, since it will *only* work if run on a host with vGPU hardware See also CLOUDSTACK-6876 - I don't have rights to duplicate these two issues, but I believe they are the same thing. Diffs - test/integration/smoke/test_deploy_vgpu_enabled_vm.py fa33bdc Diff: https://reviews.apache.org/r/22512/diff/ Testing --- Tested against a KVM host to ensure the skip logic kicks in. Thanks, Alex Brett
Re: Review Request 22232: Fix for test_01_create_volume to use the correct volume name for KVM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22232/ --- (Updated June 10, 2014, 10:09 a.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Changes --- Adding cloudstack group Repository: cloudstack-git Description --- test_01_create_volume was expecting the new volume to appears as /dev/sda when running on KVM (as this is the default volume used in util.checkVolumeSize), whereas it actually appears as /dev/vdb. This patch determines the appropriate volume name in the same way as we do for XenServer, and uses that instead. Diffs - test/integration/smoke/test_volumes.py 73c2722 Diff: https://reviews.apache.org/r/22232/diff/ Testing --- Verified the test now passes when running against a KVM host. Thanks, Alex Brett
