This Terraform module creates and configures OpenStack compute instances with optional attached storage volumes and networking configurations.

• Create OpenStack compute instances with customizable configurations
• Boot from volume with configurable size by default
• Support for attaching additional volumes
• Floating IP assignment for public access
• Security group configuration
• Integration with cloud-init for instance initialization
• Flexible networking options
• Resource tagging support with automatic app_name tagging

Before proceeding, if you lack OpenStack Application Credentials or do not know how to make them available to Ansible in your development environment, make sure to check out the EWC documentation.

💡 Checkout the EWC Knowledge Base for up-to-date information on available VM images and VM plans (i.e. flavors)

module "server" {
  source = "github.com/ewcloud/ewc-tf-module-openstack-compute?ref=1.6.0"

  app_name       = "<user-defined application name>"
  instance_name  = "<user-defined instance name>"
  instance_index = 1
  image_id       = "Rocky-9.7-20260519081947"
  flavor_id      = "8cpu-16gbmem"
  keypair_name   = "<user-created keypair name>"
  
  networks = ["internal"]

  external_network_name = "external"

  instance_has_fip = true
  
  security_groups = ["ssh"]
  
  instance_metadata = {
    owner           = "<owner name>"
    deployment-tool = "terraform"
  }
  
  tags = {
    owner           = "<owner name>"
    deployment-tool = "terraform"
  }
}

module "server" {
  source = "github.com/ewcloud/ewc-tf-module-openstack-compute?ref=1.6.0"

  app_name       = "<user-defined application name>"
  instance_name  = "<user-defined instance name>"
  instance_index = 1
  image_id       = "Rocky-9.7-20260519081947"
  flavor_id      = "8cpu-16gbmem-80gbdisk"
  keypair_name   = "<user-created keypair name>"
  
  networks = ["private-<region>-ewcloud-<tenancy name>"]

  external_network_name = "external-internet"

  instance_has_fip = true
  
  security_groups = ["ssh"]
  
  instance_metadata = {
    owner           = "<owner name>"
    deployment-tool = "terraform"
  }
  
  tags = {
    owner           = "<owner name>"
    deployment-tool = "terraform"
  }
}

{
  name           = "app-name-instance-name-01"
  id             = "instance-id"
  internal_ip    = "192.168.1.10"
  floating_ip    = "203.0.113.10"
  networks       = [/* Network details */]
  flavor_id      = "flavor-id"
  volumes        = ["volume-id-1", "volume-id-2"]
  access_address = "203.0.113.10"  # or internal IP if no floating IP
}

{
  primary  = "image-id"  # ID of image out of which the OS volume was created (NOT the volume ID); Evaluates to null if os_volume.enable = false
  volume_1 = {
    id   = "volume-id-1"
    name = "app_name_instance_name_01_volume"
    size = 100
  }
  volume_2 = {
    id   = "volume-id-2"
    name = "app_name_instance_name_01_volume2"
    size = 50
  }
}

primary holds an image ID, not a volume ID. The OpenStack provider does not report the ID of the OS volume that it creates, so this module cannot output it.

To find the OS volume, for example before taking a snapshot of it, you can list the volumes attached to the instance via the OpenStack CLI.

First, execute:

openstack server show <instance-id> -c volumes_attached

This lists every attached volume, including volume_1 and volume_2. The OS volume's ID will be distinct from volume_1.id or volume_2.id.

To validate you've gotten the OS volume's ID, run:

openstack volume show <volume-id> -c bootable

If the correct ID was provided, the above command should return:

+----------+-------+
| Field    | Value |
+----------+-------+
| bootable | True  |
+----------+-------+

1. Prefer image ID rather than the image Name as input, to guarantee reproducibility/idempotence. Consider these edge-cases:

   • There are multiple images with the same Name available

   • The image Name is passed onto a new image every few months

   There is risk of downtime/data loss if re-applying WHEN ANY OF THE ABOVE becomes true since an initial instance provisioning; whenever the image Name input is set, this module will pick the newest image ID that corresponds to said Name.

2. Always specify appropriate security groups for your instances

3. Use unique and descriptive names for instances to aid in identification

4. Consider using OS volumes for production instances for improved performance and resilience

5. Implement proper key management for your keypair_name

6. Use cloud-init userdata for consistent instance initialization

This module supports tagging of OpenStack resources using the tags variable. Additionally, the module automatically adds the app_name as a tag to all resources that support tagging. This provides consistent identification across your OpenStack environment.

• Compute Instance: Tags are implemented as metadata key-value pairs
• Volumes: Tags are implemented as a list of string tags
• Floating IPs: Tags are implemented as a list of string tags

Example of how tags are applied:

tags = {
  environment = "production"
  project     = "web-app"
}

The above will result in:

• Compute instance metadata containing: app_name, environment, and project keys
• Volumes and floating IPs tagged with: app_name, environment, and project tags

This tagging approach makes it easier to filter, identify, and manage resources in your OpenStack environment.

The following components will be included in the working environment:

All notable changes (i.e. fixes, features and breaking changes) are documented in the CHANGELOG.md.

Thanks for taking the time to join our community and start contributing! Please make sure to:

• Familiarize yourself with our Code of Conduct before contributing.
• See CONTRIBUTING.md for instructions on how to request or submit changes.

Copyright © EUMETSAT 2026.

The provided code and instructions are licensed under the MIT license. They are intended to automate the setup of an environment that includes third-party software components. The usage and distribution terms of the resulting environment are subject to the individual licenses of those third-party libraries.

Users are responsible for reviewing and complying with the licenses of all third-party components included in the environment.

Contact EUMETSAT for details on the usage and distribution terms.

European Weather Cloud <[email protected]>