All posts by Jack Kozik
Openstack RDO packstack Kilo install stuck on CENTOS 7 – MariaDB conflict
Background: I got stuck on RDO packstack Kilo install onto CENTOS7. I got some strange log entries I didn’t understand – I post the problem and the solution here for my records and maybe to help someone else.
For my RDO packstack Kilo install setup, I followed the normal Quick Start steps on a bare metal installed version of CENTOS 7 (CentOS-7-x86_64-LiveKDE-1503).
I ran the following step in the install guide:
# packstack --allinone
The packstack installed failed with the following error on the console:
Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.41-2.el7_0.x86_64' returned 1: error: Failed dependencies: You will find full trace in log /var/tmp/packstack/20150704-200908-
This is an error pointing to the following log file entry:
Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.41-2.el7_0.x86_64' returned 1: error: Failed dependencies: mariadb-server is needed by (installed) akonadi-mysql-1.9.2-4.el7.x86_64
This is only my second install using packstack, and it is my first attempt at installing RDO packstack Kilo; so, I wasn’t familiar with the troubleshoot this kind of problem. It didn’t make sense to me that packstack would be trying to uninstall (rpm -e) MariaDB. The error indicates that the uninstall wouldn’t work because another package akonadi-mysql was using it — right? is that how I read this? FYI: Akonadi is a storage service that runs under KDE… I wasn’t familiar with it.
Browsing the RDO Workaround archives , I found a short article on this topic: Packstack fails when mariadb-server is installed. The body of the article shows a log file message that is different enough from mine that I didn’t find it right away.
I tried the recommended fix to uninstall MariaDB and re-run RDO packstack Kilo:
# yum remove mariadb-server # packstack --answer-file=packstack-answers-20150704-200908.txt
This fixed my problem!
I was able to run packstack to completion and bring up the openstack horizon dashboard. Note: I didn’t re-run packstack –allinone; I followed the packstack workflow requirement to re-run an install using the answer file previously generated.
Since the workaround was written for Juno and Fedora 20, I thought the fix was just a coincidence, but in reading the details, the original problem was triggered by installing KDE ontop of Fedora 20. Since I picked a KDE distribution of CENTOS7, maybe my problem and the original workaround write-up are related?!
Respectfully submitted,
Jack
Setting up Virtual Servers in Openstack environment
Background on Setting up Virtual Servers in Openstack environment: Once I got my Openstack environment setup, and I was able to create a couple of instances, I had to figure out the easiest way of managing IP Addresses and sub-domain names for web access to each of my instances.
I needed web access to my openstack host. I needed web access to each of my instances, which are running virtually on the same host. Further, since I am running all of this on one server in my home network, I need to somehow map all of this to one external IP address.
This is nothing too new to me. I have lots of vintages of Linux servers in my basement, and I sort of know the ropes around setting up NAT-ing, Virtual Servers, and proxies. My question was: what’s the best practice? What would be the easiest?
I couldn’t find anything directly on this (let me know if you have a reference). So here’s what I decided to do.
Enable Openstack Dashboard Network Access
By default, the Openstack Horizon Django configuration strictly controls who can get access. It’s roughly localhost only. For testing purposes, I went into the settings file and removed all restrictions:
$ cd /etc/openstack-dashboard $ vi local_settings ... #ALLOWED_HOSTS = ['horizon.example.com', ] ALLOWED_HOSTS = ['*'] ZZ $ systemctl restart httpd.service
I tried making a restrictive list, but it kept getting in my way. When done setting up, I will lock this up.
I then verified from a different PC in the same subnet that http://192.168.100.154/dashboard works.
Map Openstack Host to External IP Address
Using my home router, I configured an address mapping between port 80 and my Openstack host. Here’s the screen shot:
Now verify that http://my.external.IP.address/dashboard works.
Setup an Openstack Subdomain Name
One of my domain names, jackkozik.net points to my home router’s IP address. I setup an Openstack subdomain name, using my zoneedit account — I used os.jackkozik.net. Sorry no screen shot. I am (perhaps too liberally) showing my domain name, but I am reluctant to show my IP addresses. Zoneedit is pretty quick, but distributing a new subdomain address takes anywhere from 0 to 60 minutes.
I then edit Openstack’s virtual server configuration adding os.jackkozik.net as a ServerAlias, as follows:
$ cd /etc/httpd/conf.d $ vi 15-horizon_vhost.conf ... <VirtualHost *:80> ServerName kozik4.lan ServerAlias os.jackkozik.net # Add this line ... ZZ $ systemctl restart httpd.service
Then assuming the subdomain has had a chance to get distributed, verify http://os.jackkozik.net/dashboard.
Openstack’s install scripts automatically setup this VirtualHost.
Create Subdomains for Each of My Instances
Within Openstack, I create instances that are automatically assigned IP addresses from a pool in the range of 192.168.100.100-119. Of course these instances are accessible from my home network (eg http://192.168.100.100 displays a nice Apache default screen). But I only have one external IP address and I need a mechanism to for external web access.
Absent any better approach (I hope to find one!), I am using Apache’s ProxyPass capability. I have used this for physical servers, why not use it for virtual machines?!
For starters, I created another subdomain in zoneedit. I decided to name each external instance with a letter followed by the least significant digits from the IP address. My first subdomain is named f100: That is, it is a Fedora instance and it’s running an instance mapped to 192.168.100.100. In zoneedit, I enter the subdomain f100.jackkozik.net, and I put the same external IP address that I used for os.jackkozik.net.
Within the Apache configuration files, I created a virtual server named f100.jackkozik.net, and used ProxyPass to map it to (redirect it to?) the web server running on 192.168.100.100. See the following config file:
$ cd /etc/httpd/conf.d $ vi openstackInstances_vhost.conf # This file configures all the proxy modules: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so <VirtualHost *:80> ServerName f100.jackkozik.net ProxyPreserveHost On ProxyPass / http://192.168.100.100/ ProxyPassReverse / http://192.168.100.100/ </VirtualHost> ZZ $ systemctl restart httpd.service
I created this file and put it in the conf.d directory. It automatically gets read whenever the apache web server starts.
From here, allowing enough time for zoneedit to work, I verified that http://f100.jackkozik.net worked from both my home network and from an outside network (I sometime use my desktop PC at work test this; more commonly I use the Chrome browser on my Android phone).
I edit this file for each new instance I setup.
So each of my instances think they are sitting on the internet, but really the Openstack host Apache server and my home network router’s NAT function are fooling it.
Fix ALLOWED_HOSTS
Finally, once I got everything working, I fixed ALLOWED_HOSTS to permit any traffic from my home subnet and only allow requests from URL os.jackkozik.net from the Internet. See following:
$ cd /etc/openstack-dashboard $ vi local_settings ... ALLOWED_HOSTS = ['localhost', 'os.jackkozik.net', 'kozik4.lan', ] #ALLOWED_HOSTS = ['*'] ZZ $ systemctl restart httpd.service

Walking Las Vegas Strip
I was in Las Vegas for the week. My meetings started at 8am and most nights ended at 10pm, so I didn’t get alot of time to really do anything.