In this DevStack example, I will show how to install a DevStack-based demo OpenStack solution on an existing Ubuntu 14.04 server.

DevStack is an open source project with the goal to offer a development, test or demo environment for working with OpenStack. The compute nodes are based on QEMU, a software virtualization, so do not expect any high performance from this installation. However, it helps you to get acquainted with the handling of OpenStack, to get acquainted with OpenStack’s APIs and/or even to contribute to the OpenStack project.

In this post, we will install OpenStack on an existing Ubuntu server 14.04. I have tried to follow the official documentation, but it was easy to get lost there. The official documentation has led me to some challenges related to file permissions, which you can circumvent by following the step by step guide below.

DevStack Example – Step by Step

Step 1: Install Ubuntu 14.04 Server

In my case, I have used Hyper-V and the Ubuntu Server 14.04 ISO for installing a high-performance Ubuntu server on my brand new monster Predator notebook with 64GB RAM. Hyper-V requires Windows 10 Pro license as a minimum if you are not working with Windows Server licenses. However, you can also choose to install Ubuntu 14.04.x on physical hardware, on VMware vSphere, VMware Workstation, the old VMware Server 2.0.2 or on VirtualBox.

Note: there is a nice and simple way to install Ubuntu on VirtualBox using Vagrant, which I have described in step 1 „Install a Docker Host“ in this post. The Docker host Vagrant box is an Ubuntu 14.04 machine and the Docker software does not hurt. The biggest challenge there is to successfully install VirtualBox.

The following Software needs to be installed in addition on Ubuntu:

sudo apt-get install openssh-server git

Step 2: Download DevStack from Git

Now we need to download DevStack using git:

git clone https://git.openstack.org/openstack-dev/devstack/
cp devstack/samples/local.conf devstack/

Step 3 (optional): take snapshot of your Ubuntu virtual machine (if it is a virtual machine)

At this point, I have created a snapshot (checkpoint) of the VM on Hyper-V, so I can go back any time, the installation fails.

Step 4 (necessary?): copy and edit local.conf

In the moment, it is not clear, whether it is used during installation, but I have copied local.conf from devstack/samples to devstack, as the official documentation always talks about changing local.conf file :

cp devstack/samples/local.conf devstack/

And I have changed the content of devstack/local.conf like follows:

#local.conf
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
#...
# OV: commented out
# LOGFILE=$DEST/logs/stack.sh.log
#...
# OV: commented out
#LOGDAYS=2
# I have kept following lines:
SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5
SWIFT_REPLICAS=1
SWIFT_DATA_DIR=$DEST/data

Step 5: create a non-root user called „stack“ and log in as this user

Devstack does not run as root, so we need a non-root user. You might want to re-use an existing non-root user instead, but I recommend to create it like follows:

myname@ubuntu:~$ sudo devstack/tools/create-stack-user.sh
Creating a group called stack
Creating a user called stack
Giving stack user passwordless sudo privileges

The user stack has no password, so we only can log in via su as root. In my case, myname is a sudo user, so I have loged in via the command:

myname@ubuntu:~$ sudo su stack

Step 6: copy the git repository to the „stack“ user’s home directory

This step is missing in the official documentation and had caused the installation script to fail due to wrong permissions. As user „stack“, navigate to the directory containing devstack and copy the directory to home directory:

cp -R devstack ~/

The devstack repository is not large, but if you do not want to copy it, you also could change the file permissions by using a chown -R stack:stack devstack.

Step 7: run the installation script

Now the devstack folder and its contents are owned by user stack and the installation script should run with no problems:

cd ~/devstack; ./stack.sh

-> here I was asked for the password again, even though it is defined in local.conf already. I have not investigated yet, whether the Step 4 above is necessary at all. Just re-type the password you have defined in Step 4.

After ~50 minutes, we see following last message of the installation:

2016-06-21 09:44:20.771 | stack.sh completed in 2946 seconds.

In this case, the command was running on a Hyper-V Ubuntu 14.04.3 server with only one core of the i7-6700QM CPU and only 6 Mbps Internet download bandwidth.

Step 8: log in to Horizon as admin

Unfortunately, there is no information given on what to do next. Therefore, I have had a look into stack.sh and I have found that Horizon should be available on URL http://hostname/dashboard/auth/login/?next=/dashboard/ where hostname is 192.168.178.111 in my case:

2016-06-21 (1)

Yes, perfect! Horizon is up and running.

Per trial and error, I have logged in as user „admin“ with the password I have provided above and I have reached the Identity -> Projects screen:

2016-06-21 (2)

Bingo! Time to play around!

🙂

Step 9: explore Compute Nodes

On Admin->Hypervisors, we can see that DevStack has added a single QEMU-based Hypervisor with 512MB RAM on the base ubuntu machine:

2016-06-21 (4)

Step 10: create a virtual machine / Instance

On Projects->Compute->Instances, click on „Launch Instance“:

2016-06-21 (5)

2016-06-21 (6)

and then on „Next“. Then we can choose the image, from which the instance will be built:

2016-06-21 (7)

Click on the Plus-sign next to the cirros image and click „Next“.

In the next screen, I have chosen the smallest flavor with 64MB RAM and no disk. Since the QEMU only provides 512MB, some of the other flavors should cause problems later on (can be tested later).

2016-06-21 (9)

Let us skip the other steps for now and immediately create the instance by clicking „Launch Instance“ at the bottom of the screen (you might need to scroll down). You immediately should see a green box flashing with a success message: First, there will be a task „Spawning“, which will change to „None“ in a minute or so. At the same time, the instance Power state will be „Running“.

2016-06-21 (10)

The instance is assigned a private IP address 10.0.0.2. However, is there a possibility to access the system?

Yes, from the Ubuntu system, you can ping the newly created instance:

stack@ubuntu:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=3.38 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.333 ms

However, without SSH key, we will not be able to SSH into the system; similar to AWS instances.

In 25 minutes, the German team is playing soccer in the European Contest, so I will stop now with a final dashboard screen:

2016-06-21 (11)

We have created and started a virtual machine (instance) on OpenStack.

Appendix A: Workaround for Openstack Login Error „An error occurred authenticating Please try again later“

After some days of OpenStack running with no interaction from my side, I could not log in to horizon anymore.

2016-07-03 (1)

I have found this YouTube video with information on how to fix this issue. However, I could not find any shell script named rejoin-stack.sh, as required. I have re-installed devstack instead. For that, I have issued following commands:

sudo su - stack
cd ~/devstack
./unstack.sh
sudo rm -rf /etc/keystone
./stack.sh

I had to remove the keystone folder with the rm -rf command in order to avoid an Operation not permitted failure during the execution of stack.sh. The downside of this solution is that it takes ~20 minutes of re-installation time again. At the end, I got following information:

This is your host IP address: 192.168.178.134
This is your host IPv6 address: ::1
Horizon is now available at http://192.168.178.134/dashboard
Keystone is serving at http://192.168.178.134/identity/
The default users are: admin and demo
The password: secret
2016-07-03 14:37:50.238 | WARNING:
2016-07-03 14:37:50.238 | Using lib/neutron-legacy is deprecated, and it will be removed in the future
2016-07-03 14:37:50.239 | stack.sh completed in 1082 seconds.

And I could log in again:

2016-07-03 (2)

16 comments

    1. @Jeffrey: that is a good question. Does this description on neutron networking for devstack help? Judging from this document, you need to attach a bridge (Open vSwitch, Linux bridge or MacVTap) to the Firewall/NAT Router’s network. Then you attach the developer’s notebook’s interface to the bridge which may change its MAC-address, invalidating the arp-entries until the next refresh, if the notebook is not sending a gratuitous arp reply.

      The virtual machine instances will still get private IP addresses from the fixed pool (e.g. FIXED_RANGE=“10.0.0.0/24″). This address is not known by the Internet Firewall/NAT router. However, you can assign a floating IP address (e.g. from Q_FLOATING_ALLOCATION_POOL=start=172.18.161.250,end=172.18.161.254) to the instance. The translation between private IP and floating IP is a neutron service, see here for details. All in all, if the virtual machine connects to the Internet, there is a double NAT involved: once from 10.0.0.x to 172.18.161.25x performed by Neutron, and another translation from 172.18.161.25x to the outside public IP address performed by the Firewall/NAT router.

      For incoming connections, you will need to configure port mapping (i.e. static translation of public IP and port to 172.18.161.25x and port) in the router and a similar mapping in the Neutron controller (from the 172.18.161.25x and port to a 10.0.0.x IP address and port).

      Okay, this is all theory up to now. Have you tested something like this already?

  1. Hi
    Thank for the article: I have not finished the recipe yet, but I noticed that running the script to add a user does not work unless adding HOST_IP=“your computer ip“ In stackrc.

    1. Hi Nejm, if you have followed the same steps as I did, then the HOST_IP should not be needed. However, I have found following hint in samples/local.conf (see step 2):

      ### local.conf
      # „HOST_IP„ and „HOST_IPV6„ should be set manually for best results if
      # the NIC configuration of the host is unusual, i.e. „eth1„ has the default
      # route but „eth0„ is the public interface. They are auto-detected in
      # „stack.sh„ but often is indeterminate on later runs due to the IP moving
      # from an Ethernet interface to a bridge on the host. Setting it here also
      # makes it available for „openrc„ to include when setting „OS_AUTH_URL„.
      # Neither is set by default.
      #HOST_IP=w.x.y.z
      #HOST_IPV6=2001:db8::7

      Best Regards,
      Oliver

  2. Hi,
    I followed the same steps as you did, but i am not getting the default hypervisor in the Admin>hypervisors and not able to find cirros image .Please help me out resolving this issue.

    1. Hi Vijay,
      sorry, your valuable comment/question was hidden under a pile of SPAM comments. I am sorry, to have not seen it in time. Have you succeeded in resolving your issue, finally? If so, how?
      Best regards
      Oliver

    1. I see that your question was posted quite long ago. Sorry for the late reaction.

      Good question. Have you tried to re-run stack.sh? If re-running stack-sh does not do the trick, there does not seem to be a simple way to just start the server without running stack.sh again. You may need to extract your own startup script from start.sh, I fear.

      Maybe a reverse engineering of the function „run_phase“ could be a start?

      $ grep run_phase * 2>/dev/null
      clean.sh:run_phase clean
      functions-common:function run_phase {
      stack.sh:run_phase override_defaults
      stack.sh:run_phase source
      stack.sh:run_phase stack pre-install
      stack.sh:run_phase stack install
      stack.sh:run_phase stack post-config
      stack.sh:run_phase stack extra
      stack.sh:run_phase stack test-config
      unstack.sh:run_phase override_defaults
      unstack.sh:run_phase unstack
      

      Maybe you already have found a solution to the problem? It would be great if you’d tell us (even, if you have not found a solution).
      Thanks
      Oliver

Comments

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.