Feature Request: Add keep_volume option to preserve boot volume artifacts in OpenStack builder

Abierto
  • ¿Algo no está bien?
#151 1 comentario 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
cloud, infrastructure

Línea de trabajo

Comienza rastreando cómo el OpenStack builder gestiona use_blockstorage_volume y la ruta de cleanup que elimina el volumen creado. Revisa la documentación del Packer plugin y los casos de keep_volume solicitados; después, verifica que el cleanup predeterminado no cambie, que los volúmenes conservados sobrevivan a los builds exitosos y que las instancias de compute sigan eliminándose.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

When use_blockstorage_volume = true, Packer always deletes the created volume during cleanup. There is no way to retain it.

I use Platform9 Managed OpenStack, which supports creating VMs directly from volumes, not just from images. This is a common pattern in environments where volumes are preferred over images for provisioning, because it enables storage locality, faster cloning, and immutable golden volume workflows.

The problem is that Packer does all the hard work, it creates a volume, boots a VM from it, and runs provisioners, but then DELETES the VOLUME at the end. The only artifact it can produce today is a Glance image. If you want a retained volume as your build output, Packer gives you no option.

The workaround right now is to use Terraform or Ansible after a Packer run to re-create the volume from the image. That is an unnecessary extra step. Packer already creates the volume internally ( because we use use_blockstorage_volume =true), but it just always destroys as part of its cleanup process.

I would like to request an optional keep_volume flag (default false) so the volume Packer creates is preserved after a successful build. Existing behavior stays completely unchanged when the flag is not set.

Current behavior (use_blockstorage_volume = true, skip_create_image = false):
get source image --> create volume --> provision VM --> cleanup deletes volume --> Glance image created

Requested behavior (use_blockstorage_volume = true, skip_create_image = true, keep_volume = true):
get source image --> create volume --> provision VM --> cleanup skips volume deletion --> volume retained (no image created)

Requested behavior (use_blockstorage_volume = true, keep_volume = true, skip_create_image = false):
get source image --> create volume --> provision VM --> cleanup skips volume deletion --> volume retained + Glance image created

I have implemented this in a fork and it works correctly. Happy to open a PR.

Use Case(s)

Use Case(s)

  1. Golden volume workflows : Build and harden a boot volume once. Keep it as a reusable template source for VM creation.
  2. VM provisioning from volume clones: Clone VMs from preserved golden volumes instead of re-importing images. Keeps storage locality within the same volume type.
  3. Immutable artifact lifecycle : Produce versioned, retained build artifacts. Avoid mutating existing template volumes in place.
  4. Operational safety: Prevent accidental loss of the build output that today's default cleanup causes. Retain the volume for inspection and controlled rollout.
Potential configuration
packer {
  required_plugins {
    openstack = {
      source  = "github.com/hashicorp/openstack"
      version = ">= 1.1.3"
    }
  }
}

source "openstack" "golden_volume" {
  source_image            = "<source-image-id>"
  flavor                  = "<flavor-name>"
  image_name              = "golden-linux-2026-04-13"

  use_blockstorage_volume = true
  volume_size             = 100
  volume_name             = "golden-linux-volume-2026-04-13"
  volume_type             = "<myvolumetype>"

  skip_create_image = true  # skip Glance image, volume is the target artifact
  keep_volume       = true  # retain created volume after build
}

keep_volume = false (default): existing cleanup behavior, no breaking change
keep_volume = true: created volume is retained, compute instance is still deleted

Potential References

OpenStack Cinder docs: https://docs.openstack.org/cinder/latest/
Packer plugin docs: https://developer.hashicorp.com/packer/docs/plugins
OpenStack plugin repo: https://github.com/hashicorp/packer-plugin-openstack

Lenguaje dominante
Go
Estrellas
29
Forks
27
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hashicorp/packer-plugin-openstack

Todos los issues de hashicorp/packer-plugin-openstack

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.