Skip to content

[User Story] Pin vultr provider to v2.29.0 (skip v2.30.0+ ReadResource regression) #369

Description

@noahwhite

Story Summary

As a platform engineer, I want the Vultr OpenTofu provider pinned to v2.29.0, so that plan CI doesn't crash on vultr_block_storage refresh due to a regression introduced in v2.30.0 and persisting through v2.31.0.


✅ Acceptance Criteria

  • vultr/vultr provider constraint is = 2.29.0 in all four locations: envs/dev/main.tofu, modules/vultr/block_storage/main.tofu, modules/vultr/firewall/main.tofu, modules/vultr/instance/main.tofu
  • .terraform.lock.hcl regenerated with 2.29.0 hashes
  • Renovate config updated with a packageRule that excludes vultr/vultr versions > 2.29.0 until the regression is resolved upstream
  • tofu fmt -check -recursive opentofu/ passes
  • pr-tofu-plan-develop CI is green (no Plugin did not respond crash)
  • Renovate PR chore(deps): update terraform vultr to v2.31.0 #368 (v2.31.0 bump) is closed

📝 Additional Context

  • Regression boundary: vultr_block_storage ReadResource panic (Plugin did not respond) was confirmed on v2.30.0, v2.30.1, and v2.31.0. v2.29.0 is the highest clean version.
  • Current version before fix: = 2.28.1 (pinned in GHO-109 / PR feat(GHO-109): upgrade Vultr provider to v2.28.1, remove block storage attachment workaround #318)
  • Target version: = 2.29.0
  • Module state: The null_resource attach workaround was removed in GHO-109 and does not come back with this change; we continue to rely on native attached_to_instance support.

Known side effect (separate follow-up): Upgrading from v2.28.1 → v2.29.0 causes vultr_firewall_rule resources to plan -/+ destroy and then create replacement because the provider changed how the source attribute is represented in state. Our module already uses subnet/subnet_size so configuration is correct; this is a one-time state-migration artifact. Will be handled in a follow-up (accept recreation with brief origin-firewall gap, or state rm+import to avoid).


📦 Definition of Ready

  • Acceptance criteria defined
  • No unresolved external dependencies
  • Story is estimated
  • Team has necessary skills and access
  • Priority is clear
  • Business value understood

✅ Definition of Done

  • All acceptance criteria met
  • Unit/integration tests written & passing
  • Peer-reviewed
  • Docs updated (if applicable)
  • Verified in staging (if needed)
  • No critical bugs/regressions

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions