Your own cloud, planned before it is built.

saphira-openstack is a menu-driven design, inspection and planning helper. It can look at local interfaces, Open vSwitch bridges, VLANs, ZFS pools, routes and the init system, then offer them as suggestions. It never chooses an address, adopts an interface, formats storage or starts a service without the operator deciding it.

Installing it installs tooling only. init writes an inventory after explicit confirmation; inventory checks it; plan explains the package and configuration readiness. None of those actions deploys OpenStack services.

apk update
apk add saphira-openstack

# Design the inventory. Back, Review and Cancel remain available.
saphira-openstack init

# Inspect and validate the saved design.
saphira-openstack inventory
saphira-openstack inventory --check
saphira-openstack plan

# Read the format and the deliberately non-default examples.
sed -n '1,260p' /usr/share/saphira/openstack/inventory-format.txt
ls /usr/share/saphira/openstack/examples

After the inventory is understood, install the role package that matches each machine. The controller role brings in Keystone, Glance, Placement, Nova, Neutron, Horizon, MariaDB, RabbitMQ and Memcached. The compute role brings in Nova, Neutron, libvirt, Open vSwitch and the network tools it needs. The storage role brings in Cinder and LVM. Each package has an interactive, repeatable setup command and a read-only --check mode.

# Controller: apk add saphira-openstack-controller; saphira-openstack-setup-controller; saphira-openstack-setup-controller --check
# Compute: apk add saphira-openstack-compute; saphira-openstack-setup-compute; saphira-openstack-setup-compute --check
# Storage: apk add saphira-openstack-storage; saphira-openstack-setup-storage; saphira-openstack-setup-storage --check

Controller setup asks for the controller address, region, browser-facing console host and passwords; it writes service configuration, bootstraps the databases and identity service, registers endpoints, starts the controller services and proves their HTTP endpoints answer. Compute setup asks for the controller, service password and provider network details; it probes for KVM, prepares Nova, Neutron, libvirt and Open vSwitch, then checks that the controller can see the hypervisor and agents. Storage setup asks for a controller and a dedicated volume disk; it refuses mounted or partitioned media unless the operator explicitly confirms the risk.

Cinder’s final volume-export path still depends on the iSCSI target support being available and proven end-to-end. The storage helper stops honestly at that boundary rather than claiming that a package installation has produced attachable volumes.

Saphira uses OpenRC; SaphiraD uses systemd. OpenStack service APKs package both their OpenRC init script and their systemd unit. For example, Keystone, Glance, Placement and Horizon ship /etc/init.d/NAME and NAME.service; Nova, Neutron and Cinder do the same for their individual services. Package installation alone does not enable any of them.

rc-update add keystone default
rc-service keystone start
rc-service keystone status

systemctl enable --now keystone.service
systemctl status keystone.service

Use the role setup command first; it knows the order in which its own configuration, database work and services must be handled. These commands are the visible service controls afterwards: use the Saphira form on an OpenRC machine or the SaphiraD form on a systemd machine, never both. The same pattern applies to glance, placement, nova-compute, neutron-openvswitch-agent, cinder-volume and the other packaged OpenStack services.

The inventory lives at /etc/saphira-openstack/inventory.ini. It is plain text, editable and reproducible. Every decision is written down: no hidden address, hostname, bridge, VLAN, network or storage device is invented by the helper.

# A shape, not a ready-made cloud. Use your own verified values.
[global]
domain = cloud.example
init = openrc

[node controller]
roles = controller,compute
address4 = 192.0.2.11
address6 = 2001:db8:1::11

[network management]
purposes = management
existing = yes
family = dual
cidr4 = 192.0.2.0/24
cidr6 = 2001:db8:1::/64

[operations]
credentials = interactive
ha = none

The documentation addresses above are intentionally non-routable examples. Replace every one with a value from the environment being designed. Mark an existing network or store as existing so the plan treats it as something to connect to, not something to recreate.

1. Decide what actually needs a cloud: users, projects, virtual machines, storage, networks and recovery expectations.
2. Inventory the hardware, CPU, RAM, network ports and storage. Leave headroom rather than assigning every resource to guest machines.
3. Design management, tenant, provider and storage traffic before services are installed. IPv4 and IPv6 are independent choices; neither is assumed.
4. Use saphira-openstack init, validate the result and read the plan. Correct the design on paper before making service changes.
5. Follow the role-specific guides for the deployment work and test a small, real virtual machine, network and image path before promising the platform to users.

The published controller, compute, storage and documentation role packages are useful foundations, but a package list is not proof of a finished cloud. In particular, keep the documented Cinder lifecycle and Horizon asset prerequisites in view.

Continue with the detailed guides: OpenStack architecture, controller, compute, storage and troubleshooting.