It would certainly behave better as a test system on hardware. The system survives reboots out of the box, which might make it a better candidate for more involved tests than DevStack.
#Conjure up openstack default login install#
Install time takes around 24 min - faster than the DevStack install. Just replace rocky or stein wherever queens is mentioned. I have tried this with both OpenStack versions rocky and stein, but not queens as indicated in the instructions. So that the yum-config-manager step will work correctly. The only adjustment needed was to run: yum install -y yum-utils I’m using CentOS 7 on a 6 core, 24 GB RAM, 128 GB disk VM. 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. There is still the conjure-up cluster installation (which was the original recommendation to me). 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.
#Conjure up openstack default login how to#
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. There was a bit of irony in this struggle due to all of the “works by magic” claims with conjure-up and juju. 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.īottom line, I think the conjure-up OpenStack Workstation install is busted. Other issues have been filed with exactly the same problems. I tried their guide on 16.04 and 18.04, VMs and hardware - all with no success.Ī week after filing the conjure-up issue, I’ve not heard back, and my question on has gotten little attention.
There were regularly blocked-service errors in the conjure-up logs, leading to some confusion about the actual source of the installation error(s). System setup hang: all processes were either active, blocked, or waiting - many just waiting on a machine.This was only seen on VMs (mostly 18.04), but I didn’t try much on bare metal. Machine locked up and become completely unresponsive.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. I didn’t get far in investigating this one. Specifying eth1 could allow neutron-gateway/0 to complete installation, but then I typically run into another problem with neutron-api/0. I set other options for the dataport parameter. I took a chance at tweaking the configuration parameters. It also looks like it was fixed in 2016, so I don’t think this is my problem. 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. I looked for ways that eno2 might be expected to be generated without much luck. Specifically, neutron-gateway/0 didn’t like the dataport br-ex:eno2, claiming that eno2 didn’t exist. neutron-gateway/0 error: hook failed: "config-changed".Canonical conjure-upĪ colleague had recommended Canonical’s conjure-up, so I decided to give the Workstation guide a try: I decided to look at some options that would lead to a cluster and, ultimately, a high-availability (HA) configuration. DevStack is designed for developer testing purposes, and doesn’t recover well in the event of a machine reboot. After getting a DevStack node running here, I realized that a DevStack cluster wasn’t going to be as useful as I would like.
0 kommentar(er)
