Install OpenStack and launch your first instance

Tutorials
1
Key Value
Summary Install OpenStack and launch your first instance.
Categories openstack
Difficulty 1
Author Tytus Kurek tytus.kurek@canonical.com

Overview

Duration: 3:00

Before you get started!

Welcome to OpenStack!

In this series of tutorials, we will walk you through all the necessary steps to install, configure and get started with OpenStack. Using just a single machine, you will learn how to use OpenStack for cloud infrastructure implementation purposes, from a single-node installation to large-scale clusters.

This tutorial is the first in the “Phase I - Learn OpenStack” series.

Explore other tutorials >

What is OpenStack?

OpenStack is a collection of open source projects designed to work together to form the basis of a cloud. OpenStack can be used for both private and public cloud implementation.

What is Sunbeam?

Sunbeam is an upstream project under the governance of the OpenInfra Foundation (OIF), which was created to lower the barrier to entry for OpenStack, simplify its adoption process, and set the foundation for an autonomous private cloud. Sunbeam uses cloud-native architecture and total bottom-up automation to make OpenStack more accessible to newcomers and to help users get to grips with the platform immediately.

What is MicroStack?

MicroStack (based on Sunbeam) is an OpenStack distribution designed for small-scale cloud environments. While it is available with full commercial support from Canonical, it can also be self-deployed with no friction, effectively eliminating the need for a paid consulting engagement. MicroStack currently includes core OpenStack services only, but is expected to evolve quickly to ensure full feature parity with Canonical’s Charmed OpenStack soon.

In this tutorial, you will learn how to:

  • Install OpenStack with Sunbeam
  • Launch your first instance on OpenStack

You will only need:

One fresh physical or virtual machine with:

  • The latest Ubuntu LTS installed,
  • Static IP address assigned to its primary network interface,
  • OpenSSH server installed and configured,
  • 4+ core amd64 CPU,
  • 16 GB of RAM,
  • 50 GB of SSD storage.

Install OpenStack

Duration: 30:00

We’re going to follow MicroStack quickstart installation instructions. Those aim to install OpenStack in the most straightforward way possible by making a number of assumptions. For more configurable installation, refer to guided installation instructions.

! openstackclients
If you have the openstackclients snap installed, you have to remove it first to avoid namespace conflict. Sunbeam ships with the latest version of the OpenStack client, so the openstackclients snap is redundant.

Install OpenStack

In order to install OpenStack, execute the following command:


$ sudo snap install openstack --channel 2023.1

Install dependencies

In order to install all necessary dependencies, execute the following command:


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

Bootstrap the cloud

In order to bootstrap the cloud, execute the following command:


$ sunbeam cluster bootstrap --accept-defaults

This command takes a while to finish. Be patient.

Configure the cloud

In order to configure the cloud with default options, execute the following command:


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

For more advanced scenarios, refer to guided installation instructions.

Launch an instance

In order to launch your first instance, execute the following command:


$ sunbeam launch ubuntu --name test

Sample output:


Access instance with `ssh -i /home/ubuntu/.config/openstack/sunbeam ubuntu@10.20.20.16`

At this point the instance should be accessible over the SSH protocol. In order to connect to it, execute the command from the output:


$ ssh -i /home/ubuntu/.config/openstack/sunbeam ubuntu@10.20.20.16

That’s it. You’re connected to the instance. You can use regular shell commands to execute various tasks.


$ uptime
 11:08:36 up 2 min,  1 users,  load average: 0.05, 0.05, 0.01

In the following tutorials, we’ll demonstrate how to use other images and how to customise instances during the provisioning process.

To disconnect from the instance, type exit (or press CTRL+D).

Next steps

Duration: 2:00

Congratulations! You have reached the end of this tutorial.

You can now move to the next tutorial - “2. Components” - or explore other tutorials.

In this tutorial, you have learnt how to:

  • Install OpenStack with Sunbeam
  • Launch your first instance on OpenStack

Where to go from here?

2 Likes
2

The issue

Hi there. Following this tutorial, I noticed some interesting behavior with CirrOS when trying into the instance after launching it. Using the original command ssh -i <path/to/id_microstack> cirros@<id_address>, I am met with the following output:

nucci@baragon:~$ ssh -i /home/nucci/snap/microstack/common/.ssh/id_microstack cirros@10.20.20.191
sign_and_send_pubkey: no mutual signature supported
cirros@10.20.20.191's password:

It seems like the CirrOS that comes with Microstack does not support RSA encrypted keys and thus defaults to asking for a password.

How I fixed this

In order to use the auto-generated ssh key, I had to include the additional option to my ssh command:

ssh -o "PubkeyAcceptedKeyTypes +ssh-rsa" -i <path/to/id_microstack> cirros@<ip_address>

Where to go from here

I am thinking that it might be beneficial to update the tutorials to use the extra ssh option -o "PubkeyAcceptedKeyTypes +ssh-rsa" when connecting to a CirrOS instance or just using the password login instead. Might be worth to include that the default password for CirrOS is gocubsgo (personally I am a Pirates fan) so that new users do not panic and think that they need to destroy their CirrOS instance.

3

@nuccitheboss thanks for reaching out!

I have no idea where is it coming, but for me the CirrOS image works just fine. I have updated the tutorial, however, based on your input to make sure that whoever faces this issue, knows how to bypass it. Thank you for reporting it!

1 Like
4

No problem! If it adds anything, I did deploy microstack on my Jammy machine. I do not believe it is an issue with the prior series of Ubuntu, but I have not been able to test it thoroughly.

5

Suggestion

Hello again! I would also like to suggest here is that we have new user’s install microstack with the --devmode flag with the --beta (sudo snap install microstack --beta --devmode), and then add a short blurb about Microstack still being in beta, open to contributions, and working on getting the snap to work in strict rather than classic/devmode confinement.

Reasoning

I think it will save new user’s a lot of pain in the long run as they will not be blocked by AppArmor/snap confinement in later tutorials. For example, for tutorial #5 (templates) when we import an image file, if strict confinement is enabled, you will be presented with this bug: Bug #1980993 “Unable to import new qcow2 image into Glance” : Bugs : MicroStack.

Someone new to Microstack (and the Ubuntu ecosystem) might not necessarily be familiar with the rules of snap confinement, so they might just think Microstack is broken and uninstall it rather than we’re still hammering out the kinks with strict confinement. I think I might have the fix for the confinement issues, but I think the addition of the --devmode flag to the snap install ... command would make it easier for new users who want to try MicroStack out.

6

@nuccitheboss we intentionally removed the --devmode flag some time ago once we completed the work around strict confinement. If you’re facing issues, this means there’s something wrong with it. Note that we’re currently testing MicroStack on Ubuntu 20.04 LTS only.

@billy-olsen FYI

7

While launching the CirrOS instance, on Ubuntu 22.04 host machine, I am unable to connect to the Instance with ssh, it shows Private Key cannot be used. While checking the instance logs, it seems like meta-data server is not reachable by the Instance, timeout issue happens. This happens for the Chapter 9 Instances also.

To solve this we have to add --config-drive true to the server creation command, or, force_config_drive = true into the nova-snap.conf at /var/snap/microstack/common/etc/nova/nova.conf.d/. Post this restart the microstack with snap restart, re-launch the instance, and now ssh works fine.

Detail is here https://bugs.launchpad.net/microstack/+bug/1954546.

For anyone who faces the ssh connection issue, either on CirrOS or Ubuntu 20.04 images, please add this as a note in this tutorial.

8

Hi, I was working through the old Microstack tutorial series at https://ubuntu.com/openstack/tutorials which was on Ussuri. Where can I find the series prior to the update to sunbeam?

9

The tutorials are simply updated, not archived and replaced by new ones. You can look at the history of a page in Discourse by clicking in the top-right corner of its window:

image

10

sunbeam cluster bootstrap --accept-defaults
The above command runs fine on Ubuntu Server 22.04.
But on Ubuntu 22.04 Desktop it doesn’t work fine. Infinite loading occurs on Bootstrapping Juju onto machine...

Log
[23:14:56] DEBUG Bootstrap node: roles CONTROL,COMPUTE bootstrap.py:145
DEBUG Updating /home/ubuntu/snap/openstack/common/etc/deploy-sunbeam-machine from bootstrap.py:161
/snap/openstack/201/etc/deploy-sunbeam-machine…
DEBUG Updating /home/ubuntu/snap/openstack/common/etc/deploy-microk8s from bootstrap.py:161
/snap/openstack/201/etc/deploy-microk8s…
DEBUG Updating /home/ubuntu/snap/openstack/common/etc/deploy-microceph from bootstrap.py:161
/snap/openstack/201/etc/deploy-microceph…
DEBUG Updating /home/ubuntu/snap/openstack/common/etc/deploy-openstack from bootstrap.py:161
/snap/openstack/201/etc/deploy-openstack…
DEBUG Updating /home/ubuntu/snap/openstack/common/etc/deploy-openstack-hypervisor from bootstrap.py:161
/snap/openstack/201/etc/deploy-openstack-hypervisor…
DEBUG Starting pre-flight check Check for juju snap common.py:206
DEBUG Starting pre-flight check Check for ssh-keys interface common.py:206
DEBUG Starting pre-flight check Check for snap_daemon group membership common.py:206
DEBUG Starting pre-flight check Check for .local/share directory common.py:206
DEBUG Starting pre-flight check Check for Hypervisor Hostname common.py:206
DEBUG /var/snap/openstack/common/state/control.socket service.py:109
DEBUG /var/snap/openstack/common/state/control.socket service.py:109
DEBUG Starting step ‘Login to Juju controller’ common.py:225
DEBUG Local account not found, most likely not bootstrapped / joined juju.py:1008
DEBUG Skipping step Login to Juju controller common.py:235
DEBUG Starting step ‘Bootstrap Cluster’ common.py:225
DEBUG [get] service.py:118
http+unix://%2Fvar%2Fsnap%2Fopenstack%2Fcommon%2Fstate%2Fcontrol.socket/cluster/1.0/c
luster, args={‘allow_redirects’: True}
DEBUG http://localhost:None “GET /cluster/1.0/cluster HTTP/1.1” 503 131 connectionpool.py:456
DEBUG Response(<Response [503]>) = service.py:120
{“type”:“error”,“status”:"",“status_code”:0,“operation”:"",“error_code”:503,“error”:"
Daemon not yet initialized",“metadata”:null}

       DEBUG    Sunbeam Cluster not initialized                                                       clusterd.py:68
       DEBUG    Running step Bootstrap Cluster                                                         common.py:238
       DEBUG    [post]                                                                                service.py:118
                http+unix://%2Fvar%2Fsnap%2Fopenstack%2Fcommon%2Fstate%2Fcontrol.socket/cluster/contr
                ol, args={'data': '{"bootstrap": true, "address": "192.168.60.158:7000", "name":
                "ubuntu-vm"}', 'json': None}

⠋ Bootstrapping Sunbeam cluster … DEBUG http://localhost:None “POST /cluster/control HTTP/1.1” 200 108
connectionpool.py:456
DEBUG Response(<Response [200]>) = service.py:120
{“type”:“sync”,“status”:“Success”,“status_code”:200,“operation”:"",“error_code”:0,“er
ror”:"",“metadata”:{}}

       DEBUG    [post]                                                                                service.py:118
                http+unix://%2Fvar%2Fsnap%2Fopenstack%2Fcommon%2Fstate%2Fcontrol.socket/1.0/nodes,
                args={'data': '{"name": "ubuntu-vm", "role": ["control", "compute"]}', 'json': None}
       DEBUG    http://localhost:None "POST /1.0/nodes HTTP/1.1" 200 108                       connectionpool.py:456
       DEBUG    Response(<Response [200]>) =                                                          service.py:120
                {"type":"sync","status":"Success","status_code":200,"operation":"","error_code":0,"er
                ror":"","metadata":{}}

       DEBUG    Finished running step 'Bootstrap Cluster'. Result: ResultType.COMPLETED                common.py:241
       DEBUG    Starting step 'Bootstrap Juju'                                                         common.py:225
       DEBUG    [get]                                                                                 service.py:118
                http+unix://%2Fvar%2Fsnap%2Fopenstack%2Fcommon%2Fstate%2Fcontrol.socket/1.0/config/Bo
                otstrapAnswers, args={'allow_redirects': True}
       DEBUG    http://localhost:None "GET /1.0/config/BootstrapAnswers HTTP/1.1" 404 125      connectionpool.py:456
       DEBUG    Response(<Response [404]>) =                                                          service.py:120
                {"type":"error","status":"","status_code":0,"operation":"","error_code":404,"error":"
                ConfigItem not found","metadata":null}


       DEBUG    BootstrapAnswers: ConfigItem not found                                              questions.py:282
       DEBUG    {'bootstrap': {'management_cidr': '192.168.60.0/24'}}                                    juju.py:236
       DEBUG    [put]                                                                                 service.py:118
                http+unix://%2Fvar%2Fsnap%2Fopenstack%2Fcommon%2Fstate%2Fcontrol.socket/1.0/config/Bo
                otstrapAnswers, args={'data': '{"bootstrap": {"management_cidr":
                "192.168.60.0/24"}}'}
       DEBUG    http://localhost:None "PUT /1.0/config/BootstrapAnswers HTTP/1.1" 200 108      connectionpool.py:456
       DEBUG    Response(<Response [200]>) =                                                          service.py:120
                {"type":"sync","status":"Success","status_code":200,"operation":"","error_code":0,"er
                ror":"","metadata":{}}

       DEBUG    Running command /snap/openstack/201/juju/bin/juju show-controller sunbeam-controller      juju.py:82
                --format json

⠏ Bootstrapping Juju onto machine … [23:15:00] DEBUG Command ‘[’/snap/openstack/201/juju/bin/juju’, ‘show-controller’, ‘sunbeam-controller’, juju.py:141
‘–format’, ‘json’]’ returned non-zero exit status 1.
DEBUG juju.py:257
DEBUG Running command /snap/openstack/201/juju/bin/juju clouds --format json juju.py:82
⠧ Bootstrapping Juju onto machine … [23:15:02] DEBUG Command finished.
juju.py:84
stdout={“localhost”:{“defined”:“built-in”,“type”:“lxd”,“description”:“LXD Container
Hypervisor”,“auth-types”:[“certificate”],“regions”:{“localhost”:{}}}}
, stderr={process.stderr}
DEBUG Available clouds in juju are dict_keys([‘localhost’]) juju.py:106
DEBUG There are 0 manual clouds available: [] juju.py:112
DEBUG Running step Bootstrap Juju common.py:238
DEBUG Running command /snap/openstack/201/juju/bin/juju add-cloud sunbeam --file juju.py:166
/tmp/tmp1hm4swrf --client
⠋ Bootstrapping Juju onto machine … DEBUG Command finished. stdout=, stderr=Cloud “sunbeam” successfully added to your local juju.py:168
client.

       DEBUG    Running command /snap/openstack/201/juju/bin/juju bootstrap sunbeam sunbeam-controller   juju.py:288
11

I was able to bootstrap onto a desktop installation without any issues. Can I ask what error you saw, as from your post, I am not seeing any installation errors.

13

It runs fine on Ubuntu Server 22.04, but the problem only occurs on Ubuntu 22.04 Desktop. Installing the Desktop environment on Ubuntu Server 22.04 causes the same symptoms as Ubuntu 22.04 Desktop.

‘DEBUG Running command /snap/openstack/201/juju/bin/juju bootstrap sunbeam sunbeam-controller juju.py:288’ is still loading when debugging with the ‘sunbeam -v cluster bootstrap --accept-defaults’ -v flag.

14

3
DEBUG Running command /snap/openstack/201/juju/bin/juju bootstrap sunbeam sunbeam-controller juju.py:288
Bootstrapping Juju onto machine
has been loading for over 24 hours.

Ubuntu 22.04 Desktop runs on VMware Workstation Pro installed on Windows.
VT-x is enabled in VMware.

15

I’m unable to get past the sunbeam cluster bootstrap --accept-defaults step

gonkers@openstack-demo:~$ sunbeam cluster bootstrap --accept-defaults
Error: Host FQDN and Hypervisor hostname perceived by libvirt are different, check `hostname -f` and `/etc/hosts` file
gonkers@openstack-demo:~$ hostname -f
openstack-demo
gonkers@openstack-demo:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 openstack-demo
16

I found some resolution here… Bug #2030349 “Host FQDN and Hypervisor hostname perceived by lib...” : Bugs : OpenStack Snap

In short add an additional entry in your hosts file
127.0.1.1 [YOUR_HOSTNAME].multipass [YOUR_HOSTNAME]

But now I have ran into more failures…

gonkers@openstack-demo:~$ sunbeam configure --accept-defaults --openrc demo-openrc
Writing openrc to demo-openrc ... done
gonkers@openstack-demo:~$ sunbeam launch ubuntu --name test
Launching an OpenStack instance ...
Found sunbeam key in OpenStack!
⠴ Creating the OpenStack instance ... Instance creation request failed: Server:38e3181f-74a3-47ba-b53a-0cbc8401a63b transitioned to failure state ERROR
Error: Unable to request new instance. Please run `sunbeam configure` first.

This tutorial is laden with issues, I think I’ll go try something else.