While Devstack needs 4GB RAM (or more!) the JEOS
used as the base for the Devstack VM for XenServer
needs much less. Allowing the initial install to
use 1GB means we have lower requirements overall
Change-Id: Iecaeeb4db0dffcc43c5532b5d57cb041d47047a6
Some vncviewers do not support the -via option, so default to suggesting
xl console. XenCenter continues to be an option for those running
Windows.
Change-Id: I1e53fd33d309e30a60031965e589167dcbacfbbe
os-vpx is only true after we know it's not a JEOS we're creating
Move the location we set the os-vpx flag to as we're starting to
prepare the VM for devstack
Change-Id: If736f3a7de171b8090b0bb905e04accb70470a90
The boot-time script (prepare_guest.sh) is one of the less reliable parts
of the install process. This change enables SSH into the host as well as
reporting of the IP address. This significantly helps debugging issues
now and enables moving of all other setup code to being executed over SSH.
Change-Id: I1555f1d91353ba8b75e2de4607df33ee20307a6e
This value was defined in Citrix's install-devstack-xen script, so
only worked for those using that script.
Change-Id: Iab63389f41760865f2b67f6dccd57d774e889905
Fix it properly this time by forcing a PID from run.sh and using that to track.
A second issue is that upstart may run services twice, introduce a flock test
to ensure that we only run stack.sh once as running in parallel causes issues.
Change-Id: I05990c7154366350b0f9cc3e6c70d6f34238486f
Dom0's bash does not support associative arrays, however we source
`functions` and therefore our scripts fail. This change breaks the
dependency of dom0 tools on domU functions.
Fixes bug: 1379804
Change-Id: I229e2d5f07070a9236ec612d4032c94c4361a9f6
Use the same mechanism as used for nova plugin installation, thus
avoiding the need for variables in dom0. This change will also help to
move XenServer CI to neutron in the future, as the dom0 part of the
script is not executed there.
With this change, the neutron related network will always be created and
attached even if the user wants to use nova-network.
Change-Id: I8669c94e9f0aacce2990469dbabde1ff702a2769
If the user only want to run the installation of Ubuntu - to export the
template as an xva, it just needs to specify a non-empty value for:
EXIT_AFTER_JEOS_INSTALLATION
And the script will exit after the jeos template has been created.
Change-Id: I558e2f2b18ee23c15c7e46e2f7e74543cf26b750
Buildroot on Ubuntu Trusty is slow to populate the vnc-port.
Wait for 20 seconds until the port is populated.
Change-Id: I50e5b5a161207d46e8ce0e304d816e8e5b68dbe8
Stack.log is created by stack.sh, which is started by run.sh. Using
the pid from run.sh doesn't mean that stack.log has been created yet
so wait for the log to be created before tailing
Change-Id: I86e563478949cb7bbe0d1afd80b790ba70328e3a
We know what the GUEST_PASSWORD will be, so set it during DomU
installation; therefore if the installation fails for any reason
we have a correct GUEST_PASSWORD set rather than the obscure and
undocumented 'r00tme'
Change-Id: I684646a74f2cede43667a40556e247955e042ae4
While installing devstack in XenServer's DomU we can easily
track the output so end-users have much more visibility of
both what is going on and what (if anything!) went wrong.
Change-Id: I7d12a13cea9dffda6c1388ce711b6adf76cae72c
Check that function calls look like ^function foo {$ in bash8, and fix
all existing failures of that check. Add a note to HACKING.rst
Change-Id: Ic19eecb39e0b20273d1bcd551a42fe400d54e938
As we are moving forward to test XenAPI in the gate, it is necessary to
move dom0 related modifications to be performed from domU. For this
purpose, a new user is created, and that user should be used to talk to
dom0 from domU. This change creates that user, makes it possible for
dom0 to log in to domU with that account, and configure that account to
be able to talk down to dom0.
Also move several steps to the nova xenserver plugin:
- dom0 plugin installation
- create kernels and images directory
- install console rotate script
- configure a cron to execute console rotate script
Configuration changes:
A new configuration option, DOMZERO_USER has been created, that
specifies a user account that is configured to be able to do
passwordless ssh to dom0.
Change-Id: If9de0b297a67b7cdb5de78d8dd0e8b2ca578b601
Like 'for/do' check that the while/until operator are on
the same line with the do.
Fixes some pep8 error along the way.
Change-Id: I440afe60691263365bf35310bf4212d94f30c339
we mostly have a consistent style on if/then & for/do in devstack,
except when we don't. This attempts to build a set of rules to
enforce this.
Because there are times when lines are legitimately long, and there
is a continuation, this starts off ignoring if and for loops with
continuations. But for short versions, we should enforce this.
Changes to make devstack pass are included. The fact that the
cleanup patch was so small is pretty solid reason that this is
actually the style we've all agreed to.
Part of a git stash from hong kong that I finally cleaned up.
Change-Id: I6376d7afd59cc5ebba9ed69e5ee784a3d5934a10
install_os_domU.sh failed, if the FLAT_NETWORK_BRIDGE is found in
localrc. As nova looks up the network by either name-label or bridge
name, it makes sense to enable the user to specify this parameter. As an
example, if the user wants to use name-labels to specify networks, and
those name-labels could be used in domU to create bridges:
VM_BRIDGE_OR_NET_NAME="osvmnet"
FLAT_NETWORK_BRIDGE="osvmnet"
In this case, the domU will know only about a name label, so it could be
decoupled from which xapi bridges used.
This change also adds some fixes (missing double quotes).
Change-Id: I045e367ef441be20c4e8cb8af3c1149392db796b
If the JeOS template contained an exotic network configuration, the VM
prep step might fail. This patch resets the networking of the VM before
starting it.
Fixes bug 1245607
Change-Id: I921f1fdd0709d7a7760c4bb165e32f3898098bff
Give as much VCPUs to the DevStack machine as possible. First asking
xenapi about its CPU count, and as a fallback, count the CPUs in dom0.
This should result in faster test runs.
Change-Id: I1ffb99ecd435f1d7eb5754fe9cd99f0e8ceae6dc
xenbr0 is correct for most installations, but not all. Notable xenserver-core
may use a differently named device. Since we can auto detect this, remove the
config and do so.
Change-Id: I989f6ddd5ffb526ab350f263ef6fc402c596304a
In XenServer, devstack runs inside a virtual machine. This makes it hard
for the user to interact with stack.sh should a parameter be missing.
This change will create an upstart job (devstack) that runs
stack.sh with console enabled so user can interact with it by running
vncviewer or using XenCenter.
Logging the output is also disabled, stamp files are used instead to
detect the script run status in case install_os_domU.sh is used.
As run.sh.log is removed, standard devstack logging should be used.
The change also removes the environment settings from run.sh, as they
are not needed, they should be specified in localrc. This way user
cannot get different experiences by using unstack.sh/stack.sh or run.sh
Also a proper unstack.sh is called instead of killing screen in run.sh
Change-Id: I7eb12bd74746cc7a1db3aa9fd68ece645a50001d
By exporting the LC_ALL=C we can get rid of localisation issues, as the
actual scripts are already assuming an english installation.
FIxes bug 1227527
Change-Id: Ieeebce4d53b09959146a970f3fb803201ac5ebdf
If someone was re-using an existing template, for a memory change, he
needed to re-install the vm. This change sets the osdomu mem before
starting it, so it doesn't matter how much memory did the VM had
according to the template. It also removes the memory manipulation bits
from install-os-vpx.sh.
Change-Id: Iad85f573b90c23140012c20c552a17277d9c97a0
Devstack prints out an instruction, how to look at the virtual machine's
console. The command did not include the username, so if the user had a
config file to use a different username for that network, the command
failed.
Change-Id: I5dd49169c45e26e8d2bb3d5920a1b7fa584be50f
This is primarily to satisfy the expectations of various scripts that os_*
variables are defined, and will result in a distro similar to "xs6.1.0-59235p"
Fixes bug 1211001
Change-Id: I951e1eb3a5e25f4d8773a11b15cf38157b6492fe
DevStack was using templating to speed up the setup process with
XenServer. The template already included some devstack customisations,
not just a clean OS. This change modifies devstack behaviour, so that
the template is a simple clean operating system. This makes it easier to
use custom OS as a template, potentially speeding up the tests.
related to blueprint xenapi-devstack-cleanup
Change-Id: I6cb0a7ed7a90e749b78329a8e2b65fb8b7fcfa5f
The devstack script sometimes failed to clean up the left over
instances. This patch will utilize the xe vm-uninstall force=true
command to get rid of the instances.
Change-Id: I3450e2d5c9a4b1fe8ede39c4cc5c337cd541ea35
This patch installs the cronjob that rotates/sets up the text console
logs of the guests.
Related to blueprint xenapi-server-log
Change-Id: Ie4c778b54f69519fbb80aa0d9822383f55a1e2f9
For Neutron we need an additional OVS bridge to be present. The xe
network-create command did not create the bridge immediately. A
workaround was applied to attach a network interface to that network,
forcing xapi to create the underlying OVS bridge. It turned out, that
the xe network-attach command could be used instead, so the workaround
is removed and replaced with the proper solution by this patch.
Fixes bug 1197305
Change-Id: I10cc763531b71238f0bc12a12de985f8f35d7e27
XenServer's resize uses /images as a known-path for each hypervisor.
This is a symlink to the storage repository so disks can be moved between
the /images path and the storage repository efficiently.
Change-Id: I13b39dbf5537ad45160c1af4cc10bd867b7f89c1
VM installation created a machine with multiple network interfaces. This
is a needless complexity at that point, we only need one interface. This
change removes the complex network interface setup from
install-os-vpx.sh script, so that only one network interface is created,
which is connected to the selected network (management by default). This
change also removes a lot of non-used code from install-os-vpx.sh
Specify the network to be used for ubuntu netinstall with:
UBUNTU_INST_BRIDGE_OR_NET_NAME
defaults to $MGT_BRIDGE_OR_NET_NAME.
This change also includes:
- use precise as default
Related to blueprint xenapi-devstack-cleanup
Change-Id: Ib0a0a316e849f2c2651305ea657c84820cd2bb3b
OpenStack VM had 4 interfaces, from which eth0 was connected to HIMN (Host
Internal Management Network), and not used at all. The reason for not
using this interface according to johngarbutt is:
- VNC console would not work
- migrations would not work
- many other things
This change removes the interface, thus devstack is providing the
same architecture as described in the official documentation, YAGNI
applied on the HIMN:
http://goo.gl/dmrNF
The change also modifies some defaults, so it's easier to get started:
- The Ubuntu VM is network-installed through the management network
- OS VM is getting its address on the management network through DHCP
- Default Public IP addresses aligned to stack.sh defaults
- OS Services are listening on Management Interface
Related to blueprint xenapi-devstack-cleanup
Change-Id: I73c9751ade6f4786b8b682a1994cb87f0a624379
Some kernels have lockup issues while serving cinder volumes from
file-loopback-lvm kind of cinder setup. This patch provides a way to
create an additional drive to the OpenStack VM, and use that to store
cinder volumes, thus eliminating the lockup issue. It will help when
testing XenServer. Now, you can specify devices for stack-volumes
through:
VOLUME_BACKING_DEVICE
In case you are using CINDER_MULTI_LVM_BACKEND, you can use
VOLUME_BACKING_DEVICE2
as well.
Xenserver:
Should you whish to use a 10 gig disk backend for your cinder volumes,
specify:
XEN_XVDB_SIZE_GB=10
VOLUME_BACKING_DEVICE=/dev/xvdb
Citrix is using this approach on its internal CI system to run tests
against OpenStack. This is a workaround for this bug:
https://bugs.launchpad.net/cinder/+bug/1023755
Related to blueprint xenapi-devstack-cleanup
Change-Id: Iee633d2704185bfbf9234882654c47b850fa168a
The kernel's cmdline was set during the initial devstack machine
installation. Thus, during second runs, the kernel's cmdline was not
updated. This patch extracts append_kernel_cmdline, and configures
domU's kernel cmdline every time. As some networking parameters are
passed through the kernel cmdline, this patch makes it possible to
change the network configuration, even if a cached devstack exists.
Related to blueprint xenapi-devstack-cleanup
Change-Id: I3b7175f4e83326c3e28825ac50625f6bd2a9a029
This patch makes it easier to support the all-in-one installation of
XenServer with Quantum:
- separate agents for domU and dom0 openvswitches. The domU agent's name
is "q-domua", and the dom0 agent is called "q-agt"
- create a physnet1 physical network to connect those openvswitches
Note: This patch depends on the quantum patch:
https://review.openstack.org/15022
For a diagram, see:
http://goo.gl/BuAdg
Change-Id: Iff851438553528b9051edd380ecbb2c0415cbf78
The Xenserver/XCP part of devstack was configuring the hypervisor's
connectivity to the outer world, by adding VLANs, and physical
interfaces to the virtual networks. It added a lot of complexity, and
made it hard to get started with XenServer. This patch removes that
extra complexity, so it is left as an exercise for the user.
Related to blueprint blueprint xenapi-devstack-cleanup
Change-Id: If3367335c3da8621d0afe1f6cae77511fbdbb3e2
