Skip to content

Proposal: Add helm_rollback module to kubernetes.core #31521

@saranyasridharan

Description

@saranyasridharan

What would you like to be added?

SUMMARY

Problem: No rollback support in existing Helm module

The current Ansible module kubernetes.core.helm provides support for installing, upgrading, and removing Helm releases, but it does not provide an option for performing a Helm rollback.

Helm rollback is a fundamental Helm operation, widely used in CI/CD pipelines when a deployment fails or regressions appear. Because Ansible lacks this capability, users are forced to call the Helm CLI directly via command: or shell:, which makes automation inconsistent and breaks idempotent playbook design.

There is currently no Ansible-native way to roll back a Helm release using release revision history.

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

helm_rollback

ADDITIONAL INFORMATION
Behavior:

Runs the equivalent of:

helm rollback [-n namespace] [--wait] [--timeout X]

Always reports changed: true because rollback alters cluster state.

Returns:

stdout, stderr

final release history after rollback (helm history --output json)

failed with descriptive error if helm command fails.

Idempotency:

Rollback is inherently a state-changing operation.
Therefore:

If rollback succeeds → changed: true

I could take care of writing a pull request with implementation + tests. What do you think?

Why is this needed?

Rollback is a first-class Helm action
Helm maintains release history and allows easy reversion using helm rollback. This is critical in production rollouts.

Improves reliability of Ansible-based Helm automation
Playbooks managing deployments via Ansible currently cannot perform rollbacks in a module-based native way.

Consistency with other helm modules
The collection already has:

helm (install/upgrade/delete)

helm_info (read release details)

A helm_rollback module naturally fits into this family.

Reduces need for shell commands
Using command: or shell::

command: helm rollback myapp 3

is not idempotent, hard to test, and brittle.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions