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
Labels:
Location: CERN, 1217 Meyrin, Switzerland

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...
1 comment
Read more

RabbitMQ and SSL

RabbitMQ is an AMQP provider i.e. it can reliably queue, service and maintain messages according to a range of policies and parameters. By default, it listens to plain old TCP connections and sends and receives messages over plaintext. This feature just works "out of the box". For users who wish to use SSL over TCP aka TLS, it requires a bit more work on their part. First, let's create a bunch of certificates and sign them with our own CA. For this, we'll use easyrsa3 . Easyrsa is a CLI tool to create, sign and manage your own certification authorities. It's maintained by OpenVPN team. Download easyrsa using your native package manager i.e. yum or apt-get $cp -Rp /usr/share/easy-rsa ~/easy-rsa-3   $cd ~/easy-rsa-3 $./easyrsa init-pki $./easyrsa build-ca $./easyrsa build-server-full broker [nopass] $./easyrsa build-client-full client1 [nopass] This creates three entities (collection of private keys, public keys and certificates) for a CA, a s...
Post a Comment
Read more

Motorola XT502 Custom ROMs

I purchased an Android Phone in the early days of it coming to Indian market and I able to afford it ( just got a job), during mid 2010. The recent and popular version was Éclairs. I just went up to the shop and bought a nice and shiny Motorola Quench XT3 (XT502). When in other places XT502 was having Andriod Donut, I got as a special offer Éclairs. I was happy as hell. The Droid A couple of year passes, and newer versions of Android came from Éclairs to Froyo to Gingerbread then to the bigger version upgrades like Honeycomb, Ice Cream Sandwich and then Jelly Bean. By the end of 2012, I was literally surviving on my Motorola with Éclairs. I had to upgrade, anyhow. Now more that Motorola denied any upgrades for Quench XT3 . A trivia, Android version names are taken from sugary desserts with lexicographic sequencing. So, I did up-gradation from Éclairs to Gingerbread using a custom ROM from Cyanogenmod . An excellent community of enthusiast who develop their own custom ROMs oft...
5 comments
Read more