-
Notifications
You must be signed in to change notification settings - Fork 666
Description
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 checkdoes 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_CONFIGacross 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
-
Create two scenarios:
defaultandcomponent. -
Enable shared state:
scenario:
shared_state: true -
Run:
molecule converge -s default
molecule converge -s component --shared-state -
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_CONFIGacross 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
Labels
Type
Projects
Status