Don't clear current stemcell on VM delete

[Ivaylogi98]

What

Removes the stemcellRepo.ClearCurrent() call from vm.Delete() (deployment/vm/vm.go), along with the now-unused stemcellRepo dependency it pulled onto the vm struct, NewVM/NewVMWithMetadata, NewManager, and NewManagerFactory.

Fixes #731.

Why

vm.Delete() unconditionally cleared current_stemcell_id (set it to "") whenever the old VM was torn down. Inside create-env's delete-then-recreate cycle, the intended sequence is:

1. vm.Delete() clears current_stemcell_id
2. new VM boots → cloudStemcell.PromoteAsCurrent() sets it to the new stemcell record
3. stemcellManager.DeleteUnused() reaps every record whose ID ≠ current

On the happy path, step 2 overwrites the clear from step 1, so it has no observable effect. But when the replacement VM never comes up (agent timeout, network issue, or a failure inside vmManager.Create before promote), step 2 is never reached and bosh-state.json is persisted with current_stemcell_id: "" while the stemcell record and its IaaS image remain.

On the next create-env run, FindUnused (stemcell/manager.go) treats every record as unused when the current pointer is empty (found == false), and DeleteUnused deregisters the still-in-use image (e.g. an AWS AMI). Every subsequent create_vm that references it then fails:

CPI 'create_vm' method responded with error:
CmdError{"type":"Bosh::Clouds::CloudError","message":"could not find AMI 'ami-xxxxxxxxxxxxxxxxx'","ok_to_retry":false}

This is more likely to surface on unattended pipelines that auto-retry a failed create-env.

The clear was always redundant

PromoteAsCurrent (stemcell/cloud_stemcell.go) calls repo.UpdateCurrent(id) unconditionally — it never reads the prior value — so the clear in vm.Delete() contributed nothing on the success path. It was introduced in bd573fe8 (Nov 2014) as defensive symmetry (clear on teardown, set on build), but even in that original code PromoteAsCurrent ran before DeleteUnused, so the clear only ever had an effect in the failure window, where it is purely destructive.

With it removed, a failed deploy leaves current_stemcell_id pointing at the stemcell the deployment is configured to use, so DeleteUnused leaves it alone. A genuinely superseded stemcell is still reaped — but only after a successful deploy where PromoteAsCurrent moves the pointer to a newer record.

Scope / not affected

• delete-env (deployment.Delete()) deletes stemcells through an explicit cloudStemcell.Delete() step, independent of vm.Delete() — unchanged.
• bosh delete-vm is a director API command (director.Deployment.DeleteVM) and never touches the local stemcell repo — unchanged.
• stemcell/manager.go and config/stemcell_repo.go (ClearCurrent is still used by cloudStemcell.Delete()) are left as-is. The VM.Delete() interface signature is unchanged.

Testing

• Dropped the two clears current stemcell in the stemcell repo cases in deployment/vm/vm_test.go (they asserted the removed behavior).
• go build ./... and go test ./deployment/vm/... ./stemcell/... ./config/... pass.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}