Skip to content

shared_state does not share instance_config, inventory or ephemeral directory across scenarios #4588

@J-PC

Description

@J-PC

Prerequisites

  • This was not already reported in the past (duplicate check)
  • It does reproduce it with code from main branch (latest unreleased version)
  • I include a minimal example for reproducing the bug
  • The bug is not trivial, as for those a direct pull-request is preferred
  • Running pip check does not report any conflicts
  • I was able to reproduce the issue on a different machine
  • The issue is not specific to any driver other than 'default' one

Environment

molecule 25.12.0 using python 3.12 :
- ansible:2.16.0
- default:25.12.0 from molecule
- vagrant:25.8.12 from molecule_plugins
- openstack:25.8.12 from molecule_plugins requiring collections: openstack.cloud>=2.1.0
- podman:25.8.12 from molecule_plugins requiring collections: containers.podman>=1.7.0 ansible.posix>=1.3.0
- gce:25.8.12 from molecule_plugins requiring collections: google.cloud>=1.0.2 community.crypto>=1.8.0
- ec2:25.8.12 from molecule_plugins
- docker:25.8.12 from molecule_plugins requiring collections: community.docker>=3.10.2 ansible.posix>=1.4.0
- containers:25.8.12 from molecule_plugins requiring collections: ansible.posix>=1.3.0 community.docker>=1.9.1
- containers.podman>=1.8.1
- azure:25.8.12 from molecule_plugins

OS: Fedora 42 WSL

What happened

Summary

When enabling shared_state in Molecule, the documentation states that component scenarios can reuse resources created by the default scenario.
However, only the create/destroy lifecycle is actually shared — not the necessary runtime state, such as:

  • instance_config.yml
  • inventories
  • ephemeral directory
  • connection parameters for hosts created by the default scenario

This results in component scenarios being unable to access the instances created in the default scenario, causing provisioning failures.


Expected Behavior

Based on the documentation, enabling shared_state should allow:

  • shared ephemeral state across scenarios
  • default scenario managing create/destroy for all others
  • component scenarios accessing resources created by default
  • consistent instance information (instance_config, inventory)

At minimum, this should include:

  • a shared instance_config.yml
  • a shared inventory
  • a shared ephemeral directory
  • consistent MOLECULE_INSTANCE_CONFIG across scenarios

Actual Behavior

In practice:

  • each scenario gets a different MOLECULE_EPHEMERAL_DIRECTORY
  • each scenario has its own instance_config.yml
  • the default scenario’s inventory and connection data are not propagated
  • component scenarios cannot connect to hosts created by the default scenario

Example environment variables printed during runs:

MOLECULE_EPHEMERAL_DIRECTORY: ~/.ansible/tmp/molecule.XYZ.default
MOLECULE_EPHEMERAL_DIRECTORY: ~/.ansible/tmp/molecule.ABC.component

This contradicts the documented behavior and makes multi-scenario reuse impossible.


Steps to Reproduce

  1. Create two scenarios: default and component.

  2. Enable shared state:

    scenario:
      shared_state: true

  3. Run:

    molecule converge -s default
    molecule converge -s component --shared-state

  4. Observe:

    • separate ephemeral directories
    • separate instance_config.yml
    • component scenario cannot reach hosts created in default

Impact

This prevents Molecule from being used in:

  • chained scenarios
  • multi-scenario test architectures
  • large roles where infrastructure should only be created once
  • any scenario that relies on the default scenario’s created instances

The feature behaves differently from what the documentation suggests.


Proposed Fix

Option A — Implement full shared-state

  • share ephemeral directory
  • share instance_config
  • share inventory
  • ensure consistent MOLECULE_INSTANCE_CONFIG across scenarios

Option B — Update documentation

Explain that shared_state currently only shares create/destroy, but does not share:

  • instance_config
  • ephemeral directory
  • inventory

Additional Information

  • This issue has been identified with the default driver
  • The problem is reproducible with any scenario and any provisioning workflow.

Reproducing example

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions