Skip to main content

Devstack installation with cells in multiple machines


 


Devstack is a testing and development package for OpenStack. The official devstack website has excellent but terse installation instructions, which could be daunting to a newbie.

Normally, a traditional install is pretty straightforward but problems creep in when you have to go for some particular configuration or installation like cells or a simple code-test-debug setup, the information on the main site is insufficient.

In this blog, I will enumerate the steps for setting up a cell-ular devstack installation with one parent and one child. Parent will not be instantiating any VMs s it's only a 'command centre'.


1. On both machines, install git and vim, clone the devstack repo using git.


yum install git vim
git clone https://git.openstack.org/openstack-dev/devstack
2. On both machines, open up the file 'local.conf' inside the cloned directory 'devstack'
    cd devstack; vim local.conf
3. Copy the parameters below to the file; these are mainly the passwords to be used for various services including database, rabbit mq and other services

[[local|localrc]]
        ADMIN_PASSWORD=secrete
        DATABASE_PASSWORD=$ADMIN_PASSWORD
        RABBIT_PASSWORD=$ADMIN_PASSWORD
        SERVICE_PASSWORD=$ADMIN_PASSWORD
        SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
4. Save the file and run 'stack.sh' script which will install vanilla devstack into your machine.
./stack.sh
5. After installation, open up another file, 'nova.conf' in '/etc/nova' directory. You will need a superuser access to edit it.
vim /etc/nova/nova.conf

 6. Alter the content in the file as per the instructions below. This will enable cells in the installation and will designate appropriate name and type to the cell. Parent machine will be 'api' cell and child will be 'compute' cell.

  • In the parent machine
[cells]
enable=True
name=toplevel
cell_type=api
  •  In the child machine
[default]
quota_driver=nova.quota.NoopQuotaDriver

[cells]
enable=True
name=cell1
cell_type=compute
    Change address of keystone and glance from local ip address to that of the parent machine. This is for making sure that the child cell uses key authorizations from the parent cell.
[keystone_authtoken]
auth_host, identity_uri, auth_uri
[default]
keystone_ec2_url, ec2_dmz_host
[glance]
api_server
Now installation and configurations are now partially complete. Now we need to start the cell service on both parent and child. To do this, create a new shell in the existing screen terminal and run,

7. In parent,

cd /opt/stack/nova && /usr/bin/nova-cells --config-file /etc/nova/nova.conf & echo $! >/opt/stack/status/stack/n-cell-toplevel.pid; fg || echo "n-cell-region failed to start" | tee "/opt/stack/status/stack/n-cell-toplevel.failure"


8. Kill key, horizon, n-api services at parent using Ctrl+C



9. In child,
cd /opt/stack/nova && /usr/bin/nova-cells --config-file /etc/nova/nova.conf & echo $! >/opt/stack/status/stack/n-cell-cell1.pid; fg || echo "n-cell-child failed to start" | tee "/opt/stack/status/stack/n-cell-cell1.failure"
P.S. If you change the cell name at parent or child, then make sure that the altered name is reflected in the command to invoke the cell services as described above.
 
10. Now, we need to let parent and child know of each other by pushing appropriate entries in the databases by using 'nova-manage' command. In the parent,


$ nova-manage cell create --name=cell1 --username=guest --password=secrete --hostname= --port=5672 --virtual_host=/ --woffset=1.0 --wscale=1.0

11. On the child


$ nova-manage cell create --name=toplevel --cell_type=parent --username=guest --password=secrete --hostname= --port=5672 --virtual_host=/ --woffset=1.0 --wscale=1.0
12. Restart all commands including n-cell at both parent and child machine.

13. Check installation by first monitoring the consoles of any error message getting printed (most probably in red) and then booting an instance on the parent by using 'boot' command.



Some other handy resources for learning and tweaking with devstack parameters

Comments

Post a Comment

Popular posts from this blog

Multimaster replication with Symmetric DS

Symmetric DS is an awesome tool for trigger based replication whcih works for all major database vendors, including but not limited to PostgreSQL, MySQL, MSSQL, Oracle and many others. Symmetric-DS is a java application and can execute on any platform on whcih JRE is available including Windows and Linux. Trigger based replication, in constrast to disk based (eg. DRBD ) or transaction log file shipping based or statement based , works by registering triggers on DMLs and sending the data thus generated to remote machines. Another very popular trigger based DB replication tool is Slony . Symmetric-DS in addition to being database agnostic also supports multi-master replication (MMR). MMR usecase involves multiple database nodes, connected in a pool with DML updates coming from any of them. This is different from the normal master-slave replication, where slaves are not expected to generate any data events, and the sole authority of database is the master. MMR requirement causes d...

Reset root password RHEL/Rocky/CentOS 9

Unlike the earlier versions of Rethat variants, version 9 doesn't allow single user mode to change password, as maintanance mode in 9 requires root password . Single user mode (runlevel 1) can easily be obtained by appending the word ' single ' at the end of the line starting with 'linux' by editing the entry in boot menu by pressing ' e ' at boot menu. To reset the root password on the other hand, one requires to follow a specific set of commands, At the boot menu, edit rescue mode to append 'rd.break ' at the end of the line starting with kernel. Boot with the edited line by pressing Ctrl+X or F10. At the new prompt starting with switch_root, type the following commands, mount -o remount, rw /sysroot chroot /sysroot touch /.autorelabel passwd <new root password> exit reboot