Feature Request: Add keep_volume option to preserve boot volume artifacts in OpenStack builder
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- go
- Ambito
- cloud, infrastructure
Direzione di ricerca
Inizia tracciando la gestione di use_blockstorage_volume da parte dell'OpenStack builder e il percorso di cleanup che elimina il volume creato. Esamina la documentazione del Packer plugin e i casi keep_volume richiesti, quindi verifica che il cleanup predefinito rimanga invariato, che i volumi conservati sopravvivano ai build completati con successo e che le istanze compute vengano ancora eliminate.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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)
- Golden volume workflows : Build and harden a boot volume once. Keep it as a reusable template source for VM creation.
- VM provisioning from volume clones: Clone VMs from preserved golden volumes instead of re-importing images. Keeps storage locality within the same volume type.
- Immutable artifact lifecycle : Produce versioned, retained build artifacts. Avoid mutating existing template volumes in place.
- 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
- Lingua principale
- Go
- Stelle
- 29
- Fork
- 27
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di hashicorp/packer-plugin-openstack
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Error initializing block storage client with Openstack 2026.1Forse già presa @elelaysh l’ha presa 72 giorni fa. Apertabug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
hashicorp/packer-plugin-openstack#162 · 1 commento ·
-
Packer 1.12.0-alpha1 testingAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Response Error: No image found with ID .... code 404 Not Found title Not Found (Floating problem )Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
hashicorp/packer-plugin-openstack#130 · 1 commento ·
-
enhancement good first issue
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
hashicorp/packer-plugin-openstack#116 · 2 commenti ·
Tutte le issue di hashicorp/packer-plugin-openstack
Issue simili
-
csp-probe needs efqdn to probe CSP domainsForse già presa @unknownhackerworld l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
projectdiscovery/httpx#2725 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
category:helper tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
LanternOps/breeze#11285 ·
I maintainer di solito rispondono entro 1 giorno
-
Query cache: a failed cache page read leaves the set request's read lock held, so the scan hangsAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
turbot/steampipe-plugin-sdk#986 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100