Tuskar/Devtest
Contents
Overview
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
- http://docs.openstack.org/developer/tripleo-incubator/index.html
- https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.
Instructions
Setup devtest
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.
Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.
mkdir /home/images yum install -y libvirt service libvirtd start virsh pool-destroy default virsh pool-undefine default virsh pool-define-as default dir --target /home/images virsh pool-start default virsh pool-autostart default service libvirtd restart
Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm
Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm chmod g+rw /dev/kvm
Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64 export NODE_DIST="fedora selinux-permissive" export DIB_RELEASE=20 export UNDERCLOUD_DIB_EXTRA_ARGS="" export OVERCLOUD_DIB_EXTRA_ARGS="" export OVERCLOUD_COMPUTESCALE=1 export TRIPLEO_CLEANUP=1 export USE_IRONIC=1 EOF
Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo mkdir -p $TRIPLEO_ROOT cd $TRIPLEO_ROOT git clone https://git.openstack.org/openstack/tripleo-incubator $TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine # wait around 2+ hours # mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)
If you want to e.g. redeploy Overcloud for testing purposes, you will need to source following
source tripleo-incubator/scripts/devtest_variables.sh source ./tripleo-undercloud-passwords source ./tripleo-incubator/undercloudrc source $TRIPLEO_ROOT/tripleo-incubator/cloudprompt source ~/.devtestrc
Build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \ -a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \ baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \ dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \ tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log
load-image overcloud-cinder-volume.qcow2
To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \ -a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \ baremetal swift-storage neutron-openvswitch-agent os-collect-config \ dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \ tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log
load-image overcloud-swift-storage.qcow2
To list MAC's for virsh listed machines run
virsh list --all virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2
At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.
Install Tuskar
mkdir -p /opt/stack && cd /opt/stack git clone https://git.openstack.org/openstack/tuskar
Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/install.rst. Make sure that you create the initial data.
To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first. Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3 sudo -i source stackrc heat stack-delete overcloud
Devtest will also set up Tuskar endpoints, but pointing to the undercloud machine. You need them point to your machine. This can be done by deleting and readding endpoints, but it's quicker to just modify them in mysql:
ssh heat-admin@192.0.2.3 sudo -i mysql -u keystone -p keystone Enter password: unset update endpoint, service set endpoint.url="http://<yourlocalip>:8585/" where service.type="management" and endpoint.service_id=service.id;
Next, you create a plan:
curl -i -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"name": "overcloud", "description": "overcloud"}' http://127.0.0.1:8585/v2/plans
Then you need to check out the role templates:
# use templates from this patch https://review.openstack.org/#/c/123100/ cd /opt/stack git clone https://git.openstack.org/openstack/tripleo-heat-templates cd tripleo-heat-templates git fetch https://review.openstack.org/openstack/tripleo-heat-templates refs/changes/00/123100/4 && git checkout FETCH_HEAD
And load the roles:
cd /opt/stack/tuskar .tox/py27/bin/tuskar-load-roles --config-file etc/tuskar/tuskar.conf --master-seed /opt/stack/tuskar_templates/overcloud.yaml --resource-registry /opt/stack/tuskar_templates/overcloud-resource-registry.yaml --role /opt/stack/tuskar_templates/controller.yaml --role /opt/stack/tuskar_templates/compute.yaml
Finally, you need to associate the roles with the plan:
- list the plan to get the ID
curl -i -X GET -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' http://127.0.0.1:8585/v2/plans # list roles to get their uuids curl -i -X GET -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' http://127.0.0.1:8585/v2/roles # add each role to the plan (you'll have to run this once for each role) curl -i -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"uuid": "<role_uuid>"}' http://127.0.0.1:8585/v2/plans/<plan_uuid>roles
Add Horizon and Tuskar-UI
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.
.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc source /root/stackrc
Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py
Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111
Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111
If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest sshfs root@lab-machine:/opt/stack/ ~/devtest
Script for installing Tuskar and Tuskar UI
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.