This reverts commit e921ec6ec79c50096d58264d60c15091969ff888.
CLOUDSTACK-7408: sshClient.py - removing function load_host_keys(). This function is used to load host keys from local host keys file and to save back the host key. It is not needed while running test cases because we are connecting to unknown host anyway and don't want to use any local host key file. We have the AutoAddPolicy for missing host key file, hence whenever ssh connects to a new host, it will save the host key in memory temporarily.
Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
Installed flask package and removed the disk expert recipe in
system vm template to keep only one partition
Signed-off-by: Frank Zhang <frank.zhang@citrix.com>
This reverts commit e921ec6ec79c50096d58264d60c15091969ff888.
CLOUDSTACK-7408: sshClient.py - removing function load_host_keys(). This function is used to load host keys from local host keys file and to save back the host key. It is not needed while running test cases because we are connecting to unknown host anyway and don't want to use any local host key file. We have the AutoAddPolicy for missing host key file, hence whenever ssh connects to a new host, it will save the host key in memory temporarily.
Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
Test data to deploy new data center and execute test using the deployed zone
Signed-off-by: sanjeev <sanjeev@apache.org>
Incorporated review comments provided in RR 25097
Fixed review comments mentioned in RR25293
Conflicts:
tools/marvin/marvin/config/test_data.py
(cherry picked from commit 9e5da759b315955cf5bc8d606f6929ac1603708f)
Test data to deploy new data center and execute test using the deployed zone
Signed-off-by: sanjeev <sanjeev@apache.org>
Incorporated review comments provided in RR 25097
Fixed review comments mentioned in RR25293
Conflicts:
tools/marvin/marvin/config/test_data.py
It is simpler to expect that rvm setup is done outside of this build.
The buildacloud.org jenkins has rvm installed/enabled by default so
does not invoke rvm.
Running --export creates the .ovf and the .vmdk files referenced
from that .ovf in one go. Guessing/predicting the names of the .vmdk
files is not fool-proof.
The backticks in the Vagrantfile template were getting evaluated by bash.
This caused some harmless but confusing error messages to appear on running
the build. Easy fix is to remove them.
* bundle install needs to run before running the vbox cleaning scripts,
so move prepare step before clean step
* feature branches have / in their name which is a bad character to
put into filenames
Veewee supports exporting vagrant boxes out of virtualbox, out of the box.
However, it assumes that it can export a disk if the shutdown of the vm that
is using that disk has succeeded. This assumption is not strictly always true
(see previous commit). So, we replicate the bit of logic in veewee for making
vagrant boxes.
This has the added side benefit of creating an .ovf export only once, rather
than once for vmware and then again for vagrant.
Having experimented with many edge cases of running multiple build.sh
commands in parallel / against busy virtualbox setups, the only really
reliable way to produce consistent images is to not do these commands
in parallel and to not do them while the machine is doing many other
things.
If virtualbox or the machine that hosts it is very busy, and/or it has
a lot of disks it knows/knew about, and/or its tuesday, behavior may
be a bit different.
Realizing this reality, this commit adds some scripts that try really
hard to set virtualbox back to known/healthy state before building.
In 8e2d06153b3d5ec1540fac1c8fbc97b5d2b58a8e I mistakenly/accidentally
a apt-get update.
As
https://wiki.debian.org/Multiarch/HOWTO
explains, apt-get update is needed after adding a new architecture.
