Skip to content

How it works

Melvin PETIT edited this page Aug 27, 2026 · 1 revision

How it works

The chain

you            Terraform      OpenStack API      libvirt      KVM
 |                 |                |               |          |
 +--> make demo -->+--> nova-api -->+--> compute -->+--> the instance

Terraform describes, the API decides and coordinates, KVM runs. Ansible is absent from that chain on purpose: it configures the inside of a machine that already exists, it does not create one.

Day one, building the platform

  1. Terraform creates the Azure VM, a VNet, a public IP and a security group that opens port 22 to your address only
  2. The inventory is generated from the Terraform outputs, so Ansible never holds a hardcoded address
  3. The playbook waits for cloud-init, adds swap, creates the stack user, clones DevStack, renders local.conf and runs stack.sh
  4. stack.sh builds every OpenStack service from source and starts them as systemd units

Only step 1 touches infrastructure you own. Everything after it happens inside the VM.

How OpenStack knows about its servers

Nobody scans the network. An agent called nova-compute runs on each machine that hosts instances, connects to the message queue and announces itself with its free capacity. The scheduler then picks a host from that inventory.

openstack compute service list   # the agents the cluster knows about
openstack hypervisor list        # the machines and their resources

Adding a server to a real cluster is therefore just installing that agent and pointing it at the controllers.

Day two, using the cloud

make demo creates five resources: a keypair, a security group, two rules, and the instance, plus a floating IP and its association.

Two addresses to keep apart:

  • 10.0.0.x is the instance address on the OpenStack private network. It exists only inside the host
  • 172.24.4.x is the floating IP, reachable from the host itself. It is what makes ssh -J work in one hop from your laptop

Naming trips everyone once: web-01 is the instance name in OpenStack, cirros is the Linux account inside the image. Same distinction as azureuser on an Ubuntu VM.

Security choices worth copying

  • No credential in the repository. The lab password is generated into .env, which is gitignored, and the playbook fails loudly when it is missing
  • Every security group CIDR is a required variable, so nothing defaults to 0.0.0.0/0
  • Horizon is never exposed. The dashboard is reached through an SSH tunnel, because a lab password on a public port is a free ride for anyone scanning
  • Host keys are checked with accept-new, which trusts a first contact but still refuses a key that changed later

Clone this wiki locally