After getting a DevStack node running here, I realized that a DevStack cluster wasn’t going to be as useful as I would like. DevStack is designed for developer testing purposes, and doesn’t recover well in the event of a machine reboot.

I decided to look at some options that would lead to a cluster and, ultimately, a high-availability (HA) configuration.

Canonical conjure-up

A colleague had recommended Canonical’s conjure-up, so I decided to give the Workstation guide a try:

https://ubuntu.com/openstack/install#workstation-deployment

Initially, I hit one of three problems:

1. neutron-gateway/0 error: hook failed: "config-changed"
   Specifically, neutron-gateway/0 didn’t like the dataport br-ex:eno2, claiming that eno2 didn’t exist. Confirmed. I looked for ways that eno2 might be expected to be generated without much luck.
   
   This github issue looks like it describes the problem almost perfectly (except for the name of the network interface), but the fix/correction makes no sense to me. It also looks like it was fixed in 2016, so I don’t think this is my problem.
   
   I took a chance at tweaking the configuration parameters. I set other options for the dataport parameter. Specifying eth1 could allow neutron-gateway/0 to complete installation, but then I typically run into another problem with neutron-api/0. I didn’t get far in investigating this one. If I’m running into these kinds of problems following what should be a straight-forward install guide, then I have no idea how deep the issues go.
   
2. Machine locked up and become completely unresponsive. This was only seen on VMs (mostly 18.04), but I didn’t try much on bare metal.
   
3. System setup hang: all processes were either active, blocked, or waiting — many just waiting on a machine. This was more rare.

There were regularly blocked-service errors in the conjure-up logs, leading to some confusion about the actual source of the installation error(s).

This is not a good start for Canonical. I tried their guide on 16.04 and 18.04, VMs and hardware — all with no success.

I’ve filed an issue with conjure-up: https://github.com/conjure-up/conjure-up/issues/1612

I asked a question: https://askubuntu.com/questions/1157568/how-to-install-openstack-with-novalxd-on-ubuntu-16-04

A week after filing the conjure-up issue, I’ve not heard back, and my question on askubuntu.com has gotten little attention. Other issues have been filed with exactly the same problems. This one is the most active: https://github.com/conjure-up/conjure-up/issues/1618

It seems odd to me that such simple instructions posted by a major OS vendor would be allowed to get to a state where they fail so completely.

Bottom line, I think the conjure-up OpenStack Workstation install is busted. There was a bit of irony in this struggle due to all of the “works by magic” claims with conjure-up and juju. Their magic lacks some potency.

The only good thing to come out of this was that I figured out how to interact with juju — a service that looks a bit like a Puppet/Chef/Ansible installer/manager. It looks like it has support for all kinds of different cloud types and vendors, but if those integrations work like this busted localhost install, I’m not sure that I’ll get much out of them.

There is still the conjure-up cluster installation (which was the original recommendation to me). More on that coming soon.

PackStack

I mentioned that this was an option in the first article, and I was fed-up with conjure-up, so I decided to look at OpenStack on CentOS.

I’m using CentOS 7 on a 6 core, 24 GB RAM, 128 GB disk VM.

I found this guide: https://linuxhint.com/install_openstack_centos/
The only adjustment needed was to run:

yum install -y yum-utils

so that the yum-config-manager step will work correctly.

I have tried this with both OpenStack versions rocky and stein, but not queens as indicated in the instructions. Just replace rocky or stein wherever queens is mentioned.

That’s how it should be done. Install time takes around 24 min — faster than the DevStack install.

The system survives reboots out of the box, which might make it a better candidate for more involved tests than DevStack. It would certainly behave better as a test system on hardware.

Unfortunately, when looking closer into clustering and HA configurations with packstack, it starts to look a little weaker.

Mentions

Throughout my investigation some other OpenStack options have popped up:

• Mirantis – This is a professional OpenStack (and then some) system. It looks like these guys know what they’re doing, and they charge accordingly. There might have been a free evaluation option, but I prefer to try things that are unencumbered by licenses.
• MicroStack – This name popped up in the AskUbuntu question. I don’t know much about it except that it doesn’t sound like it supports a high-availability configuration. Though they say it’s slated for 2020/2021.

Scripting

A quick test with some scripts written to interact with the DevStack install reveals that I had some things hard-coded to work with the DevStack install. The big adjustment I had to make was in the lookup of OpenStack service endpoints. Given the OpenStack architecture it makes sense that communication points could be different across different clusters. I wrote a bit about that here.

Next Steps

Several months into this project, I have a couple of ways to set up a demonstration installation of OpenStack on a single node, Python scripts to interact with it in some basic ways, and a technique for delivering data for project testing purposes. However, I still don’t have a system that takes advantage of the primary OpenStack capabilities: compute pooling across multiple hardware nodes. More on that to come.