Module ansible: release notes

v0.1.1

Release date: August 22, 2026.

A patch release: the objects a run creates are renamed to the prefix reserved for the module.

Highlights

• The runner Pod and the Secret with its input are now named d8a5e-*, the prefix reserved for this module, so a namespace listing shows who owns them.
• Nothing else changes: the API, the way a run is written, and what a playbook does when it runs are the same as in v0.1.0.

Fixes

• The runner Pod and its input Secret carry the prefix reserved for the module. A run that is already going keeps its Pod across the update: Pods are found by the label the controller puts on them, not by name.

Docs

• The guide no longer calls the tail of a runner Pod name a hash of the run. The apiserver appends it, and it differs between attempts to start the same run; a hash appears in a name only when a long run name has to be shortened.

v0.1.0

Release date: August 20, 2026.

The first release of the ansible module: Ansible playbooks run on Deckhouse Virtualization Platform virtual machines through the Kubernetes API, without an Ansible control node of your own.

Highlights

• Playbooks are run by creating a resource. The module picks the virtual machines, runs ansible-playbook against them in a temporary Pod, and writes the result back to the resource — no separate host with Ansible installed, no inventory to maintain by hand.
• Target virtual machines are selected the way everything else is selected in Kubernetes: by labels or by name. The inventory is built from their current addresses at the moment of the run.
• Playbooks come from where they already live: written inline in the resource, stored in a ConfigMap, or taken from a Git repository, including a private one with dependencies installed from requirements.yml.
• Runs can be put on a schedule with a separate resource, in cron syntax with a time zone, so recurring configuration does not need an external scheduler.
• One playbook serves several environments: a run carries its own variables, written in the manifest or taken from a Secret or a ConfigMap, and can execute only the part of the playbook its tags select.
• The outcome is readable without digging through logs: run phase, per-host results, failed tasks, and the reason a machine was skipped are all in the resource status.

New features

• AnsibleRun — a one-shot run: target virtual machines, SSH credentials from a Secret, playbook, and runner options.
• AnsibleRunSchedule — recurring runs from a template, with a time zone, suspension, concurrency policy, and limits on how many finished runs are kept.
• A run can go through an additional network of the sdn module, a project one or a cluster-wide one: the runner attaches itself to the named network and takes the address of a machine from it. The network needs an address pool — without one neither the machine nor the runner gets an address there. Available in commercial editions.
• Targets can be named by address (target.type: Hosts) — for machines whose address the platform cannot see, and for everything else that answers SSH beside them: physical servers, network appliances, machines of other clusters. Their variables and groups are written in the run itself. Available in commercial editions.
• Authentication by SSH key or by password, with privilege escalation and Ansible Vault through the same Secret: the keys are ssh-privatekey, password, username, become-password and ansible-vault-password.
• Per-machine inventory variables can be set with annotations on the virtual machine, so one playbook serves machines that differ in detail.
• A run carries its own variables (playbook.vars): a value written inline as any YAML the playbook expects, or taken from one key of a Secret or a ConfigMap. A value from another object reaches the playbook without being copied into any object of the module and without appearing in the arguments of the runner process.
• Whole sets of variables are taken from a YAML document in a Secret or a ConfigMap (playbook.varsFiles) — the manifest form of -e @vars.yml, and the place for what a project keeps in group_vars. Values keep the types they were written with.
• A run can execute a part of the playbook: playbook.tags selects the tasks and playbook.skipTags leaves them out, exactly as ansible-playbook treats them. A filter that matches no task ends the run successfully and says so in the status, so a mistyped tag does not pass for an ordinary successful run.
• Runner options: check mode (dryRun), diff, and Ansible verbosity level.
• Run status reports the phase, the summary of the Ansible run, per-host results, failed tasks with their output, and the commit a Git playbook was taken from.
• Machines that cannot be configured right now are reported as skipped with a reason instead of failing the whole run — for example, a machine already busy with another run.
• Runs are reported to Prometheus: the phase of every run, and for finished ones their count by outcome, how long they took, and how their hosts ended up. A schedule carries a Grafana dashboard of its own, shown on its page in the console — whether it still works, whether it got slower, and whether the park behind it is degrading.

Known issues

• The module works with addresses the platform knows: the main network address in status.ipAddress, or an address of an additional network that has an address pool. An address configured inside the guest OS by hand, or handed out by an external DHCP server, is invisible to the platform — such hosts are named by address (target.type: Hosts).
• Additional networks require the sdn module, an address pool on the network and a DHCP client in the guest OS on that interface; IPv4 only.
• AnsibleRun is immutable: to run a playbook again, create a new resource.
• SSH credentials are read from a Secret in the same namespace as the run.
• The module is at the Experimental stage: the API may change in later releases.

Dependencies

• Deckhouse Kubernetes Platform 1.68 or later. In the Community Edition a run targets virtual machines of the platform over the main network; targets named by address and additional networks are available in commercial editions only.
• The virtualization module is a recommended dependency: it is not declared as a hard one, but the only supported target is a Deckhouse Virtualization Platform virtual machine, so without it there is nothing to run playbooks against.
• The sdn module — only for runs in additional networks; runs over the main network do not depend on it.
• Ansible Core 2.21.2 in the runner image. Collections are not bundled: a playbook brings its own through requirements.yml.