OpenStack Setup¶

To run edgeContinuum services on your own OpenStack cloud, make sure the cloud has what the platform needs, upload and tag the images Kubernetes nodes boot from, and register the cloud as an infrastructure in the console. You then offer services on it through service configs. This is a task for organization administrators.

Prerequisites¶

On your workstation¶

OpenStack CLI (python-openstackclient) installed.
Credentials for the OpenStack project the platform will use, with your clouds.yaml or RC file sourced in your shell, and the right to upload images to that project (typically the member role).

Use the CLI to prepare images: neither Horizon nor Skyline can manage image tags.

In your cloud¶

Your cloud needs	Needed for
A load balancer service (Octavia) that offers the `amphora` or `octavia` provider	Registering the infrastructure in the console
The tagged base images described below	Kubernetes clusters and Fully managed PostgreSQL
An external network	Kubernetes clusters (every service config that offers them attaches its clusters to one) and Fully managed PostgreSQL
Block storage (Cinder)	Volume types, persistent volumes in Kubernetes clusters, and Fully managed PostgreSQL
A flavor with at least 2 vCPU and 4 GB RAM, enabled in the infrastructure's catalog	Fully managed PostgreSQL (the platform's default minimum)

Fully managed PostgreSQL runs on a Kubernetes cluster the platform creates, so it needs everything Kubernetes clusters need.

The platform's OpenStack account¶

Everything the platform does on this infrastructure happens in the one OpenStack project its credentials sign in to. Upload the node images to that project too, or make them visible to it (for example, as public images).

In that project, the platform creates and deletes:

networks, subnets, routers and security groups;
servers (VMs and Kubernetes nodes) and their ports;
load balancers, for Kubernetes API servers and for LoadBalancer services in clusters;
floating IPs on the external network, for Kubernetes API servers and LoadBalancer service addresses;
block storage volumes, for persistent volumes in clusters;
SSH keypairs, which belong to the OpenStack user it signs in as;
an application credential for each Kubernetes cluster, which the cluster uses to manage its own load balancers and volumes.

The account needs a role that allows all of this in the project. On most clouds that is the member role, plus the role your cloud's load balancer policy requires (often load-balancer_member). The platform doesn't check roles when you register the infrastructure; missing rights show up as failed operations later. If the platform signs in with an application credential, create it as unrestricted, so that it can create the per-cluster application credentials.

When you import existing resources, the platform lists what the account can see in that project: the project's own resources, plus networks that are shared or external, and the keypairs of its own OpenStack user.

Prepare the Kubernetes node images¶

Kubernetes cluster nodes don't boot from the catalog's images. Each node looks up its image in Glance by a tag for its Kubernetes version; you can name the image anything. Your edgeContinuum contact or platform operator provides the QCOW2 image file for each version.

Supported versions¶

Kubernetes version	Required image tag
1.34	`ubuntu-2404-kube-1.34`
1.33	`ubuntu-2404-kube-1.33`
1.32	`ubuntu-2204-kube-1.32`

These are the platform's default versions and tags. Your platform operator can configure other versions or tags, so confirm the list with them.

Exactly one image per tag

For each version, exactly one image visible to the project must carry the tag. If no image carries it, or more than one does, nodes for that version can't be created and cluster provisioning fails.

Upload and tag an image¶

Repeat these steps for each version you want to offer:

Set the tag for the version and the path to its image file:

TAG=ubuntu-2404-kube-1.34
IMAGE_FILE=/path/to/image.qcow2

Upload the image to Glance with its tag:

openstack image create \
  --disk-format qcow2 \
  --container-format bare \
  --file "$IMAGE_FILE" \
  --tag "$TAG" \
  "$TAG"

If the image is already uploaded, tag it instead: openstack image set --tag "$TAG" <image-id>.

Check that exactly one active image carries the tag:

openstack image list --tag "$TAG"

Expected output:

+--------------------------------------+-----------------------+--------+
| ID                                   | Name                  | Status |
+--------------------------------------+-----------------------+--------+
| <image-id>                           | ubuntu-2404-kube-1.34 | active |
+--------------------------------------+-----------------------+--------+

Replacing an image

Upload the new image with the tag, then remove the tag from the old image so that only one image carries it:

openstack image unset --tag "$TAG" <old-image-id>

Register the infrastructure in the console¶

In the sidebar, open INFRASTRUCTURE > Overview.
Select a region, then one of its zones. If you don't have any yet, create a region and a zone in it first (see Infrastructure).
Click Create Infrastructure.

The wizard walks through the provider (OpenStack), the configuration, the credentials, the resources to offer, and a review. Nothing is created until you click Submit. Each infrastructure counts against your organization's quota.

Configuration¶

Give the infrastructure a name, for example edge-madrid-01, and check its Region and Zone (filled in from the zone you started from). Regions and zones are platform groupings, not OpenStack concepts.

Credentials¶

This step sets how the platform signs in to your cloud.

Under Endpoint, enter:

Keystone URL: your identity endpoint, for example https://keystone.example.com:5000/v3.
OpenStack region: the region's name inside your cloud, for example RegionOne.

OpenStack region is your cloud's own region name, not the platform Region from the previous step.

Under Sign-in, choose how the platform signs in. Every field is required.

Application credential (recommended)Username & password

An application credential is scoped to one project, and you can revoke it without changing a password. Create one in your cloud's dashboard under Identity > Application Credentials, marked unrestricted (see The platform's OpenStack account), then enter its Credential ID and Secret (the secret is shown only once).

Enter the OpenStack Username and Password, the Domain (prefilled with Default, which most clouds use), and the project to work in as both its Project name and its Project ID. Both must identify the same project: the platform signs in to the project by its ID, and the tools that build Kubernetes clusters on your cloud are given both. Find the ID in your cloud's project list or with openstack project show <name>.

Click Verify credentials to test them. Next verifies them too, so you can only continue once the platform has signed in to your cloud.

Custom CA certificate¶

If your OpenStack endpoints use a certificate from a private or internal certificate authority, open Advanced below the sign-in fields and add the CA certificate: drop a PEM file (up to 10 KB) or paste it. It must contain the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines, each on its own line. Leave it empty if your endpoints use a publicly trusted certificate.

Resources¶

This step reads its options live from your cloud, using the credentials you entered. Click Reload from cloud to read them again. You can change everything in this step later from the infrastructure's page.

Catalog: the flavors (machine sizes) and images people can pick for VMs and clusters. This seeds the infrastructure's catalog; you can add more later.
Disk types (volume types): the Cinder volume types offered as storage classes on Kubernetes clusters with Storage (CSI), and, if you select several, the default one. The list is empty if your cloud has no block storage.
DNS name servers (optional): addresses given to new networks, for example 8.8.8.8. Kubernetes cluster subnets get only the IPv4 ones.
Load balancer: the balancing method and provider (Octavia or Amphora). The platform preselects them when it can read them from your cloud.

Select a volume type if clusters need storage

With no volume type selected, Kubernetes clusters with Storage (CSI) have no default storage class. See Storage (CSI).

A load balancer is required

If your cloud offers no load balancer the platform can use, you can't add the infrastructure with these credentials.

If the platform can't check your cloud's load balancer options, it offers every supported method and provider and preselects none: choose them yourself. Adding the infrastructure then fails if your cloud lacks the provider you picked.

Review¶

Check your choices and click Submit.

Manage the infrastructure¶

Settings, the catalog and service configs are managed from the infrastructure's page; see Managing an infrastructure.

Rotate credentials¶

Click Update Credentials on the infrastructure's page and enter the new credentials (the current ones are never shown). This works while the infrastructure is active or degraded.

Rotation changes the secret, not the account: the Keystone URL, OpenStack region, project and user must stay the same. You can change the password, or switch to a new application credential created by the same user in the same project. To connect a different cloud, project or user, register a new infrastructure.

Next steps¶

Create a service config and set up Kubernetes clusters and PostgreSQL databases on it. See Service configs.
Create Kubernetes clusters on the new infrastructure.

Registering an infrastructure needs infra_create in the organization, and managing it infra_update; the OrganizationAdmin role has both. See Infrastructure Permissions.