Sovereign Cloud Stack

One platform — standardized, built and operated by many.

Let's put the cloud in a box #2

Kurt Garloff March 15, 2023

This blog post is part of a multi-series publication. Read more about how to initially set up the cloud-in-a-box system in the first part of this blog post: Let’s put the cloud in a box

Usage of the system

There are a number of web interfaces available for exploration of your cloud; they are listed in the documentation of the cloud-in-a-box on the OSISM repo on github. If you just want to bookmark one page, you should use the Homer dashboard which has links to all the other web interfaces.

The cloud comes preconfigured with a test project, the smaller half of the standard SCS flavors, a CirrOS and an Ubuntu image. It also has a public network created that allows created VMs to talk to the network that your CiaB host is connected to (and to the internet if outgoing connections to the internet are available on the CiaB host) and allocate floating IPs from. The OpenStack core service are deployed as well as Octavia and Designate.

OpenStack API / command line access

The documentation describes the easiest way to access use the command line interface: When you connect to the Cloud-in-a-Box manager system via SSH, you can use the container there with the installed OpenStack CLI tools and the configuration is already done for you. Just export OS_CLOUD=test or export OS_CLOUD=admin to access the OpenStack API with normal user or admin privileges respectively via the command line interface tool openstack.

You can also do it from the wireguard-connected client directly. Install the python3-openstackclient client tools there (from your distribution or via pip) and configure the cloud in your ~/.config/openstack/clouds.yaml and secure.yaml.

You can do by copying over clouds.yml and secure.yml from /opt/configuration/environments/openstack/ on the CiaB manager and also /etc/ssl/certs/ca-certificates.crt to avoid SSL errors. You can move the latter into a directory that you have write access to and adjust the references in clouds.yaml. You may drop the octavia and system entries from clouds.yaml and secure.yaml and you also might rename the two remaining entries in ciab-admin and ciab-test to avoid creating naming conflicts with other entries that you may already have in your collection of clouds.

Here is how it look like on my system:

You can of course also use Terraform and other Infrastructure-as-Code tools with these credentials.

So what to use this for?

With the test user, you have a situation similar to the one you had when you signed up with an SCS IaaS cloud provider. So you can look at the horizon dashboard and create resources there. The same is of course possible using API calls using the openstack client command line tooling, the python SDK or IaC tools. One difference though is that your cloud is a lot smaller, so you will run out of resources (typically RAM and disk) if you start too many large VMs.

It is thus a really useful demo system. Be aware however that with preconfigured documented passwords, this system is easy prey for any hacker when connected to the internet.

You can start the openstack-health-monitor to monitor performance and availability of your system. If you use the optimization -O to cause it to talk directly to the service endpoints with the issued token, you need to pass export OS_EXTRA_PARAMS="--cacert ~/.config/openstack/ciab-certificates.crt", as these direct calls don’t use the settings from the clouds.yaml file. Note that in my CiaB setup, no amphora image was available, so testing the load balancer with the standard amphora provider is not possible. You can test the OVN provider using -LP ovn, but expect errors due to

Here’s an example run:

garloff@xps13kurt(//):/casa/src/SCS/openstack-health-monitor [0]$ export OS_CLOUD=ciab-test
garloff@xps13kurt(ciab-test):/casa/src/SCS/openstack-health-monitor [0]$ export IMG="openSUSE 15.4"
garloff@xps13kurt(ciab-test):/casa/src/SCS/openstack-health-monitor [0]$ export JHIMG="openSUSE 15.4"
garloff@xps13kurt(ciab-test):/casa/src/SCS/openstack-health-monitor [0]$ export FLAVOR="SCS-1V:2:5"
garloff@xps13kurt(ciab-test):/casa/src/SCS/openstack-health-monitor [0]$ export JHFLAVOR="SCS-1L:1:5"
garloff@xps13kurt(ciab-test):/casa/src/SCS/openstack-health-monitor [0]$ export OS_EXTRA_PARAMS="--os-cacert ~/.config/openstack/ciab-certificates.crt"
garloff@xps13kurt(ciab-test):/casa/src/SovereignCloudStack/openstack-health-monitor [1]$ ./ -O -C -D -N 2 -n 6 -s -LP ovn -b -B -T -i 2
Running v1.88 on host
Using APIMonitor_1678961257_ prefix for resrcs on ciab-test (nova)
 Send alarms to  
 Send  notes to  
 *** Start deployment 1/2 for 1 SNAT JumpHosts + 6 VMs ***  (ciab-test) --tag APIMonitor_1678961257

This will run two iterations with benchmarks creating 6 VMs plus 1 JumpHost in 2+1 Networks, running benchmarks, booting directly from the images, talking directly to the service endpoints (to save keystone roundtrips) and testing OVN loadbalancer. Again, expect errors for the OVN LB connections (after some backend members have been killed). If the health-mon fails to connect to your Jump Host, your neutron-metadata-agent has failed. (This happened sometimes on some older version of Cloud-in-a-Box.)

This was with my favorite openSUSE images, which are available from this OTC bucket

You can also run the SCS compliance checker and it will correctly report that you are lacking some of the mandatory SCS flavors.

In addition you have OpenStack admin access. So you can do things like creating flavors, register public images, or look at the hypervisor(s).

On the management host, you can maintain the system. You analyze log files or you update the kolla containers.

You can also access the Docker containers to test changes. Obviously, if you do this, you have created a state that is no longer clean from a manager perspective; in the best case, the next container refresh will undo your custom changes. In the worst case, you’ll manage to cause serious breakage.

Here are some things we have used the Cloud-in-a-Box system for:

k8s cluster-API

Getting the Kubernetes Cluster Management to work with our k8s-cluster-api-provider reference implementation is a bit complicated, as the current logic to set up the capi management server does not propagate the custom CA. The custom CA then also subsequently needs to be pushed to the OpenStack cluster API provider (capo) and to the OpenStack Cloud Controller Manager (occm). While this can be done manually, it does involve quite some steps. We are working to handle this, but this will only happen after R4 is out. We plan to publish third blog article then.

For now, we would advice anyone setting up SCS environments to avoid using custom CAs but instead go for properly signed TLS certificates, for example via Let’s Encrypt.

Version history:

About the author

Kurt Garloff
CTO Sovereign Cloud Stack @ Open Source Business Alliance
While working on Physics as student and researcher in Dortmund, Wuppertal and Eindhoven, Kurt started to work with and on Linux, with first patches to the SCSI layer in the mid 90s. He has spent his post-university life in Open Source, as kernel engineer, leader of SUSE Labs (kernel, compiler, X11, security), and engineering and business leadership at SUSE. Since 2011 he has been working on Open Source cloud software, at Deutsche Telekom, as Freelancer, at T-Systems (as chief architect for the OTC) and also has been serving on the Open Infra Foundation's board. Since 2019 he has been pushing the Sovereign Cloud Stack idea which resulted in a publically funded project that he now technically leads. He still loves to occasionally write code (mostly python these days) or at least test out code from the colleagues and project. He spends his free time with his family or with running and playing table tennis.