This issue happens on KVM as well.
This is because the volume info is missing in the CopyCommand once the volume has been removed.
When the KVM agent tries to process the command, it will throws a NPE.
This issue happens on KVM.
Normally the SSVM will process the CopyCommand from snapshot to template.
However, Ovm3HypervisorGuru chooses a KVM hypervisor to process the CopyCommand.
This is obviously wrong.
CLOUDSTACK-8981 coded a more obscure host and clear failure message test fails when port is reachable so prevent it as much as possible
making sure that all kinds of weird developers can work with it
* pr/965:
CLOUDSTACK-8981 coded a more obscure host and clear failure message test fails when port is reachable so prevent it as much as possible making sure that all kinds of weird developers can work with it
Signed-off-by: Remi Bergsma <github@remi.nl>
While running test_isolate_network_FW_PF_default_routes it is expected
that SSH'ing into a VM does not work immediately. However, when it fails
(as expected) witht he follwoing error
====Trying SSH Connection: Host:192.168.23.12 Uer:root
Port:22 RetryCnt:1===
Traceback (most recent call last):
File "/home/jenkins/workspace/mccloud/mct-run-marvin-tests@2/venv/lib/python2.7/site-packages/marvin/sshClient.py", line 121, in createConnection timeout=self.timeout)
File "/home/jenkins/workspace/mccloud/mct-run-marvin-tests@2/venv/lib/python2.7/site-packages/paramiko/client.py", line 251, in connect retry_on_signal(lambda: sock.connect(addr))
File /home/jenkins/workspace/mccloud/mct-run-marvin-tests@2/venv/lib/python2.7/site-packages/paramiko/util.py", line 270, in retry_on_signal return function()
File /home/jenkins/workspace/mccloud/mct-run-marvin-tests@2/venv/lib/python2.7/site-packages/paramiko/client.py", line 251, in <lambda> retry_on_signal(lambda: sock.connect(addr))
File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args)
error: [Errno 113] No route to host
it would try to print a message that generates a actual error:
DEBUG: ====Trying SSH Connection: Host:192.168.23.12 User:root
Port:22 RetryCnt:0===
test_isolate_network_FW_PF_default_routes
(integration.component.test_routers_network_ops.TestIsolatedNetworks):
CRITICAL: EXCEPTION: test_isolate_network_FW_PF_default_routes:
Traceback (most recent call last):,
File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
testMethod()',
File "/home/jenkins/workspace/mccloud/mct-run-marvin-tests@2/test/integration/component/test_routers_network_ops.py", line 448, in test_isolate_network_FW_PF_default_routes self.fail("Failed to SSH into VM - %s" % (public_ip.ipaddress.ipaddress)),
"AttributeError: 'unicode' object has no attribute 'ipaddress'"
CLOUDSTACK-8815 : Issues with cloudstack-management init script
When a management server is halted or rebooted, the cloudstack-management init script does not successfully kill the associated java process. There will always be an error about "Cannot find PID file". The script should be reworked so that there are no errors and java is killed correctly.
This appears to be due to the script using the basename of the script:
NAME="$(basename $0)"
To look for the pid file:
if [ -f /var/run/$
{NAME}
.pid ]; then
This does work correctly if the script is run directly (basename will be "cloudstack-management", so "cloudstack-management.pid" file is found). However when a server is halted or rebooted, the script is not run directly but via the symlinks in /etc/rc.d/rc0.d/ and /etc/rc.d/rc0.d/, respectively. The symlinks are named "K20cloudstack-management" so the script looks for a pid file named "K20cloudstack-management.pid" which does not exist.
screenshots:
Before fix:
After fix:
* pr/799:
CLOUDSTACK-8815 : Issues with cloudstack-management init script
Signed-off-by: Remi Bergsma <github@remi.nl>
CLOUDSTACK-8979: add virtio support for CentOS/RHEL 7 on KVM@borisroman @NuxRo could you test it?
* pr/963:
CLOUDSTACK-8979: add virtio support for CentOS/RHEL 7 on KVM
Signed-off-by: Remi Bergsma <github@remi.nl>
The labeling was broken. Only labels assigned at zone creation
were used, changing labels was not working. Tested with changing
a label and checking it.
As a bonus fixed the consistency of KVM in Dutch compared to other
traffic labels in dutch and copied in the OVM3 translated label
in other languages.
cloud-apidoc module depends on cloud-client-uiWhen building the cloud-apidoc module a script called `./build-apidoc.sh` is executed with an argument that points to `../../client/target/cloud-client-ui-${project.version}/WEB-INF/lib`. The script uses that argument to build a Java classpath. However, since the cloud-apidoc module does not explicitly depend on cloud-client-ui, a parallel maven build will often fail because the required jars are not present when needed.
Error message when build fails:
```
Error: Could not find or load main class com.cloud.api.doc.ApiXmlDocWriter
```
This PR makes the dependency explicit.
Resulting build:
```
mvn clean install -T4 -Pdeveloper,systemvm
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 09:02 min (Wall Clock)
[INFO] Finished at: 2015-10-20T13:31:30+02:00
[INFO] Final Memory: 98M/1526M
[INFO] ------------------------------------------------------------------------
```
* pr/958:
cloud-apidoc module depends on cloud-client-ui
Signed-off-by: Remi Bergsma <github@remi.nl>
Earlier the deployment planner was not handling the case of virtual routers.(In Explicit Dedication)
It was only handling for all instance VMs/user VMs.
Added code for checking the case of Virtual Routers.
CLOUDSTACK-8933 SSVm and CPVM do not survive a reboot from APIThis closes PR #930 as well.
I Rebased @bvbharat's PR with latest Master and tested the SSVM/CPVM and the routers: rVPC; VPC; VR; and RVR.
* pr/959:
CLOUDSTACK-8933 - Improves the the test internals of the SSVM/CPVM
CLOUDSTACK-8933 - Replace infinite loop by a for loop
CLOUDSTACK-8933 SSVm and CPVM do not survive a reboot from API
This closes#930
Signed-off-by: Remi Bergsma <github@remi.nl>
CLOUDSTACK-8960: Remove Citrix Resources from test_data.pyReplace URLs related to templates and ISOs with the ones accessbile to everybody in the community.
I have copied all the templates and ISOs to my webspace at http://people.apache.org/~sanjeev/ so they can be accessible from anywhere.
* pr/939:
CLOUDSTACK-8960: Remove Citrix Resources from test_data.py Replace URLs related to templates and ISOs with the ones accessbile to everybody in the community
Signed-off-by: Remi Bergsma <github@remi.nl>
Corrected sentenceCorrected the sentence as the previous one didn't make sense
* pr/951:
Corrected sentence
Signed-off-by: Remi Bergsma <github@remi.nl>
CLOUDSTACK-8971 - Improve the current test_privategw_acls.py - Read cofiguration from the zone: template id; template id; and domain id
- Create Account and VPC Offering
- Add cleanup resources
* pr/957:
CLOUDSTACK-8971 - Improve the current test_privategw_acls.py
Signed-off-by: Remi Bergsma <github@remi.nl>
Add optional fields: iprange and fordisplay to Marvin base.py class method Vpn.create
Add optional field: passive to Marvin base.py class method Vpn.createVpnConnection
CLOUDSTACK-8952 - The redundant routers are facing a race condition due to several KeepaliveD/ConntrackD restartsThis PR fixes the following issues:
* KeepAliveD being restarted for each action performed on the routers
* ConntrackD configuration being copied for each action performed on the routers, causing several restarts
* ACS Management Server relying in the JSON file to report which router is Master/Backup
* Public Interface on both routers are in UP state due to several places checking if the interface is UP/DOWN and trying to do KeepAliveD
* Removing all the sleeps from the test_vpc_redundant.py - those are no longer needed
* When KeepAliveD calls master.py during the election, update the cmdline.json to set the router in Backup mode: the election will take care of changing it afterwards.
* Add LB stats_rules to iptables INPUT chain
* The RVR public interface is set to eth2 instead of eth1 - as in the rVPC. Make sure the check works in both cases
Those fixes make all the routers very stable, with ACL, FW, PF and LB working just fine!
* pr/940:
CLOUDSTACK-8952 - Make the checkrouter.sh compatible with RVR as well
CLOUDSTACK-8952 - Make the tests rely on the interface state other than the json file
CLOUDSTACK-8952 - Reduce retried from 20 to 5
CLOUDSTACK-8952 - Do not rely in the router state on the json file to report back to ACS
CLOUDSTACK-8952 - Make the check for master more reliable
CLOUDSTACK-8952 - Restart dnsmasq everytime the configure.py runs
CLOUDSTACK-8952 - Make sure the calls to CsFile use the new logic of commit/is_changed methods
CLOUDSTACK-8952 - Make sure we restart dnsmasq if the configuration file changes
CLOUDSTACK-8952 - The public interface was comming UP in the Backup router
CLOUDSTACK-8952 - Do not restart conntrackd unless it's needed
CLOUDSTACK-8952 - Do not replace the conntrackd config file unless it's needed
CLOUDSTACK-8952 - Remove the '--vrrp' search criteria form the CsProcess constructor call
Signed-off-by: Remi Bergsma <github@remi.nl>
Marvin module depends on APIdoc moduleWhen building the developer tools, if the build is sequential then the marvin module always gets build after the apidoc module. However, it the build is parallelised (-Tn option in maven) it sometimes happens that maven tries to build the marvin module before building the apidoc module. That difference in the order makes it impossible to build marvin because it depends on the artefacts of the apidoc module.
This PR makes the dependency between marvin an apidoc explicit.
* pr/948:
Marvin module depends on APIdoc module
Signed-off-by: Remi Bergsma <github@remi.nl>
CLOUDSTACK-8888: Xenserver 6.0.2 host stuck in disconnected state aftXenserver 6.0.2 hosts are stuck in disconnected state after CS upgrade to 4.6. This is because xenserver602resource class is not there in 4.6 branch and existing hosts running on v6.0.2 are not handled properly.
* pr/861:
CLOUDSTACK-8888: Xenserver 6.0.2 host stuck in disconnected state after upgrade to 4.6
Signed-off-by: Remi Bergsma <github@remi.nl>
- If we stop/start a router, the state in the file will still say MASTER, when it is actually not
- Checking the state based on the interface (eth1) state
- Once master.py is called by keepalived, save the state in the json file to BACKUP just to make sure it's also written there
