Single-node quickstart

This tutorial shows how to install OpenStack (based on project Sunbeam) in the simplest way possible. It will deploy an OpenStack 2023.1 (Antelope) cloud.

The cloud will only allow access to its VMs from the local host. To enable access from any host on your network, follow the Single-node guided tutorial instead.

Requirements

You will need a single machine whose requirements are:

  • physical or virtual machine running Ubuntu 22.04 LTS
  • a multi-core amd64 processor ideally with 4+ cores
  • a minimum of 16 GiB of free memory
  • 50 GiB of SSD storage available on the root disk

Caution: Any change in IP address of the local host will be detrimental to the deployment. A virtual host will generally have a more stable address.

Deploy the cloud

Install the openstack snap

Duration: 5 minutes
Depending on internet connection speed to required resources may be shorter or longer.

Begin by installing the openstack snap:

sudo snap install openstack --channel 2023.1

Prepare the machine

Duration: 1 minute

Sunbeam can generate a script to ensure that the machine has all of the required dependencies installed and is configured correctly for use in OpenStack - you can review this script using:

sunbeam prepare-node-script

or the script can be directly executed in this way:

sunbeam prepare-node-script | bash -x && newgrp snap_daemon

The script will ensure some software requirements are satisfied on the host. In particular, it will:

  • install openssh-server if it is not found
  • configure passwordless sudo for all commands for the current user (NOPASSWD:ALL)

Bootstrap the cloud

Duration: 30 minutes
Depending on internet connection speed to required resources may be shorter or longer.

Deploy the OpenStack cloud using the cluster bootstrap command and accept software defaults:

sunbeam cluster bootstrap --accept-defaults

Configure the cloud and obtain credentials

Duration: 5 minutes
Depending on internet connection speed to required resources may be shorter or longer.

Now configure the deployed cloud using the configure command:

sunbeam configure --accept-defaults --openrc demo-openrc

The --openrc option specifies a regular user (non-admin) cloud init file (demo-openrc here).

Launch a VM

Duration: 2 minutes
First VM launch will take longer.

Verify the cloud by launching a VM called ā€˜testā€™ based on the ā€˜ubuntuā€™ image (Ubuntu 22.04 LTS). The launch command is used:

sunbeam launch ubuntu --name test

Sample output:

Launching an OpenStack instance ...
Access instance with `ssh -i /home/ubuntu/.config/openstack/sunbeam ubuntu@10.20.20.200`

Connect to the VM over SSH using the provided command. Note that the VM will not be ready instantaneously; waiting time is mostly determined by the cloudā€™s available resources.

Related how-tos

Now that OpenStack is set up, be sure to check out the following how-to guides:

1 Like

This direction could be confusing especially for people new to OpenStack. The SSH command actually fails because it takes some time until the VM actually gets ready and the SSH service is ready to accept the connection on top of OpenStack.

$ ssh -i /home/ubuntu/snap/openstack/223/sunbeam ubuntu@10.20.20.53                                                                                                          
(no response)
^C


$ ssh -v -i /home/ubuntu/snap/openstack/223/sunbeam ubuntu@10.20.20.53
OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 10.20.20.53 [10.20.20.53] port 22.
debug1: connect to address 10.20.20.53 port 22: Connection refused
ssh: connect to host 10.20.20.53 port 22: Connection refused

Thank you Nobuto. I added a sentence.

@pmatulis I think this tutorial needs a warning so that in this mode, OpenStack gets deployed without working Cinder, so even though it shows up in the GUI, itā€™s not usable. Iā€™d make an explicit warning that instances should be launched in a ā€œCreate New Volume = Noā€ mode with a link to the multi-node mode setup for those looking for block storage support.

The fix for this will soon be backported to 2023.1/stable.

I think this tutorial could benefit from including VM launch steps with multipass.

When using multipass launch --name microstack --cpus 4 --memory 16G --disk 50G, the installation would complain about lack of memory, 17G works fine.

Also, when running sunbeam cluster bootstrap --accept-defaults, the default fqdn is the name of the multipass instance, in this case microstack. This isnā€™t valid and hence it errors: Error: Host FQDN and Hypervisor hostname perceived by libvirt are different, check hostname -fand/etc/hosts file.

This can be mitigated by renaming the host name in /etc/hosts file to something like microstack.local.

1 Like

@charlie4284 thanks for the feedback.

Even though I agree that having multipass in between is useful for trying MicroStack and this is why itā€™s referenced at the home page of microstack.run, Iā€™m not sure this is something we should recommend in the official product documentation that is intended to serve people looking for using MicroStack in real production environments.

On the other hands, I canā€™t imagine anyone using the quickstart guide for the production installation, so we could potentially include it there with a note that the whole quickstart guide is not intended to serve real production use cases.

Thoughs @billy-olsen, @jamespage, @pmatulis ?

@tkurek thanks for the reply!

I see - the reason Iā€™ve given this feedback was because somewhere in the older versions of the tutorial, I canā€™t quite seem to find the reference to it anymore :confused: , I remembered seeing multipass being as a part of the tutorial (from my vague memory, it included multipass launch ... command lines).

Also, if the tutorial wonā€™t start from the initializing a testing VM step, I think it might be beneficial to add that this tutorial will make changes to the environment and hence running it in a separate environment is recommended. What do you think?

To be specific about my use-case, Iā€™m using it to test github-runner-operator charm w/ OpenStack, which requires additional setup w/ firewalls & routing. Hence, it is likely that I would write an internal post on how to setup Microstack using Multipass but just wanted to know if the source documentation would be updated as to not have duplicate information :slight_smile: .

A tutorial, by definition, should have one way of doing things so my stance is that Multipass should not be included. It sounds like your proposal would fit better into a tutorial on this present Discourse instance but in this category (and tag) instead:

https://discourse.ubuntu.com/tags/c/tutorials/34/openstack

1 Like

Thank you for the information about the ā€œError: Host FQDN and Hypervisor hostname perceived by libvirt are differentā€. You saved me many hours of work.

1 Like

Hello. Can you be more precise by what changes you are referring to?

Thereā€™s an issue raised against multipass for this and the dns resolution. There are discrepancies with what the hostname -f output and how the libvirt code resolves hostnames within the openstack-hypervisor snap.

Thereā€™s a few things we should probably do to fix this including:

  1. Update the docs to indicate that on a multipass instance the full hostname should be added to the /etc/hosts file.
  2. Potentially update the prepare node script to detect when running in a multipass instance and make the modifications clearer.
  3. Update the error message to be more helpful by indicating what the values are and providing a bit more detail on how to rectify this.
1 Like