# Should automation developers be starting with role-only collections? **URL:** \ **Category:** Project Discussions\ **Tags:** role, testing, molecule\ **Created:** [July 15, 2026, 8:31pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251 "2026-07-15T20:31:28Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Jeff\_Pullen](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jeff_pullen/32/5318_2.png) [@Jeff\_Pullen](https://forum.ansible.com/u/Jeff_Pullen)\ **Post date:** [July 15, 2026, 8:31pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/1 "2026-07-15T20:31:28Z")
**Should automation developers be starting with role-only collections?** I genuinely cannot answer that, and following up on my earlier posts about group two (the folks testing roles and playbooks rather than Python modules), what surprised me digging in is that there does not seem to be an official answer either. The guidance across [docs.ansible.com](http://docs.ansible.com) is not consistent about it, and I could not find an authoritative position anywhere on whether a role or playbook author should be working inside a collection at all. That unanswered question matters because **the tooling has quietly answered it for us**. The modern, supported, CI-ready testing path ([`ansible-creator`](https://docs.ansible.com/projects/creator/) scaffolding, [`pytest-ansible`](https://github.com/ansible/pytest-ansible), [`tox-ansible`](https://docs.ansible.com/projects/tox-ansible/), [`antsibull-nox`](https://docs.ansible.com/projects/antsibull-nox/)) has converged on the `extensions/molecule/` layout, which only exists inside a collection. So the moment you want supported testing, you are in collection territory whether or not you ever decided a collection was the right unit for your work. Getting reliable information along the way is harder than it should be too. In an earlier post I said standalone role testing was stable and well documented. Having gone through the current state, I have to walk that back. The examples are abundant, but most of them predate Molecule’s “ansible-native” rework ([v25.9, September 2025](https://docs.ansible.com/projects/molecule/)), which changed how scenarios are configured, and they teach a model the project now treats as legacy. Those older resources are still what you find first: a search for how to test a role surfaces the old `driver:`/`platforms:` style, some of it very recent (I found a [tutorial dated April 2026](https://computingforgeeks.com/ansible-molecule-testing/), tested against Molecule 26.4.0, still teaching the deprecated config). Meanwhile Molecule’s current docs no longer include a getting-started guide specifically for a role, only [playbooks](https://docs.ansible.com/projects/molecule/getting-started-playbooks/) and [collections](https://docs.ansible.com/projects/molecule/getting-started-collections/), and the official guidance is not consistent about which shape it assumes (the [Dev Tools testing page](https://docs.ansible.com/projects/dev-tools/user-guide/testing/) documents only a role within a collection, while the [Sample Ansible setup](https://docs.ansible.com/projects/ansible/latest/tips_tricks/sample_setup.html) page assumes bare roles and playbooks). To be clear, the recent Molecule docs rework by @cidrblock and team is a genuine and much-needed improvement. The problem now is discoverability: the good current material is not what a search turns up. Even past the outdated information, the structural complexity is real, and it spikes as soon as content moves into a collection. This is where I think we under-serve role-only users: - **A wave of additional tools arrives at once.** Beyond Molecule you are now looking at `ansible-creator`, `ansible-test`, `pytest-ansible`, and one of `tox-ansible` or `antsibull-nox`, plus the `galaxy.yml` and namespace and versioning that come with the collection format itself. Each looks optional in isolation, but they interlock. - **Documentation and examples for role-only collections are thin.** Most collection-testing material assumes there are modules in the collection, so a role-only author has to work out which of that long list actually applies to them. - **Each of those tools brings its own configuration,** and that is where the hidden complexity lives: - **Where the config even lives.** Molecule alone splits across a shared `extensions/molecule/config.yml`, a per-scenario `molecule.yml`, and an `inventory.yml`, and then `tox-ansible` or `antsibull-nox` adds a `tox.ini` or a `noxfile.py` plus `antsibull-nox.toml` on top. - **Redirection and inheritance between those files.** The shared base config is inherited and overridden per scenario, and one tool invokes another (for example `tox-ansible` runs Molecule through `pytest-ansible`), so tracing what actually ran, and why, means chasing config across several files. - **The config is python-centric.** A `noxfile.py` is literally Python, and the pytest integration test is a Python file. Someone whose whole world is YAML is now editing Python to run a test. - **None of it is familiar.** nox, tox, and pytest are conventions from the Python developer world, not something a YAML automation author has any reason to already know. So I think we need to definitively answer this question first, **should a role or playbook author be starting in a collection?** If the answer is yes, then the role-only, content-focused case needs to be tailored to automation developers writing YAML rather than python. It needs to be first-class and out of the box, with its own documentation and examples and not something an author reverse-engineers from module-oriented tooling. > Originally posted in [Unified Collection Testing Strategy - Kick off & Landscape Overview](https://forum.ansible.com/t/unified-collection-testing-strategy-kick-off-landscape-overview/45799) - Split into separate post. ---
**Author:** ![Jeff\_Pullen](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jeff_pullen/32/5318_2.png) [@Jeff\_Pullen](https://forum.ansible.com/u/Jeff_Pullen)\ **Post date:** [July 21, 2026, 12:22am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/2 "2026-07-21T00:22:28Z")
**Proposal: A standard arrangement for Molecule scenarios** Molecule can already test a role, a playbook, or a collection. What it lacks is a standard arrangement for how a scenario is put together, so that is left to each author, and there is nothing shared to lint or validate against. The current lack of a unifying standard has resulted in a learning cliff and conflicting examples. The point of a standard is a path an ordinary role author can follow without building that machinery. I want to propose one. A scenario is three separable things: - **Machinery** : how a test host is created and destroyed, plus the boilerplate that wires the run together. - **Inventory** : which images and providers you test against. - **Content** : the `converge` that runs your code and the `verify` that checks it. Only the content should differ between scenarios. Today Molecule makes you copy all three into every one. The standard I am proposing is that machinery and inventory live once, and a scenario holds only its content. Nothing here needs new tooling; every piece already exists, and we need to agree on how they are arranged. **Machinery: the platform collection owns create/destroy.** A platform collection ships its provisioning once, as ansible-native playbooks callable by fully-qualified name: ```auto containers.podman/ └── playbooks/ ├── molecule_create.yml └── molecule_destroy.yml ``` Every scenario then looks the same, whether it tests a role or a collection: ```auto # role: /molecule/default/ # collection: /extensions/molecule/default/ # identical below the parent either way: ├── molecule.yml ├── create.yml # import_playbook: containers.podman.molecule_create ├── destroy.yml # import_playbook: containers.podman.molecule_destroy ├── converge.yml # yours └── verify.yml # yours ``` `containers.podman` owns the podman create/destroy, `amazon.aws` owns the EC2 one. You import it by name instead of copying it. (`david_igou.molecule_provisioners` already implements this pattern; it needs to be a standard, not one person’s collection.) The `create.yml`/`destroy.yml` files are one-line imports; they are separate files only because Molecule resolves these by filename, and lifting that so `molecule.yml` can name the playbook directly is a small enhancement worth making later. **Inventory: which images you test is data, not config.** Today the image and provider set lives inside each scenario’s `molecule.yml`, or in shared config that authors inherit through non-standard tricks. The first means editing every scenario to change the set; the second is the kind of unofficial inheritance that has to be excluded from ansible-lint and schema validation, because there is no standard shape for it. The set should instead be data the create playbook consumes. This falls out of the create/destroy contract below. Updates to what images to test can be centrally maintained in a single inventory. It is flat data you can open and read, not config merged from up the tree. **Content: `converge` and `verify` are all that differ.** Once machinery and inventory are standardized, a scenario carries only the code that runs the thing under test and the assertions that check it. **What the standard removes.** - One scenario format across roles, playbooks, and collections, all under the molecule directory. No separate `tests/integration/targets/` tree to keep in sync. - The image inventory lives in one data file, instead of being repeated in every `molecule.yml` or inherited through non-standard config. - Shared files can be linted and schema-validated, because they have a standard shape instead of being ad hoc. - The silent zero-host success (a run that matches no hosts still reports pass) is closed by the create contract. - There is a blessed pattern to point people at, instead of the deprecated `driver:`/`platforms:` examples that are currently the most discoverable. **What I am asking this group to ratify.** Four things: 1. The location and names of a collection’s provisioning playbooks and the inventory: `playbooks/molecule_.yml`. 2. One scenario format shared by a role, a playbook, and a collection. 3. The convention that the image and provider inventory is data the create playbook consumes, not config repeated per scenario. 4. A small create/destroy input/output contract: instances come from inventory, destroy loops the same group, and create fails loudly instead of reporting success over zero hosts. That contract is what makes provisioners interchangeable across platforms and closes the silent-failure gap. I have worked it out and can bring it as a starting point. **This is a light lift for collections.** A collection that manages a thing generally already starts and stops it to test itself, so shipping `molecule_create`/`molecule_destroy` is mostly naming work, given clear standards and copy-ready examples. It stays optional: a collection that ships nothing loses nothing. Users / teams are also empowered to create and share their own “providers” using their existing collection distribution methods. **What deserves its own thread.** A real standard still has to settle: whether create/destroy ships as a playbook or a role and how it surfaces in Galaxy alongside modules and roles; how inputs are expressed and validated (argument specs, defaults); and who owns the contract and how it is versioned without breaking consumers. I will open that thread and bring the fuller contract if there is appetite here. ---
**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\ **Post date:** [July 21, 2026, 9:07am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/3 "2026-07-21T09:07:58Z")
> [@Jeff\_Pullen](#): > > Molecule can already test a role, a playbook, or a collection. … plugins and modules. > [@Jeff\_Pullen](#): > > Molecule resolves these by filename, and lifting that so `molecule.yml` can name the playbook directly is a small enhancement worth making later. That was proposed by me (among other things) in 2023 [https://github.com/ansible/molecule/issues/3919](https://github.com/ansible/molecule/issues/3919) This was before the molecule “redesign” and issue is closed now. So I suppose this is rejected. But I strongly believe that having explicit playbooks that have to be copied from one molecule scenario to another is a bad thing (and molecule still forces one to do that) > [@Jeff\_Pullen](#): > > 1. The location and names of a collection’s provisioning playbooks and the inventory: `playbooks/molecule_.yml`. See my proposal in the link above - molecule playbooks to provision/delete/etc should be in separate collection, not just separate files. > [@Jeff\_Pullen](#): > > 1. The convention that the image and provider inventory is data the create playbook consumes, not config repeated per scenario. Why it should be a convention? There are plenty of scenarios where this kind of complexity is not required. But idea is good. What is stopping you from removing platform section from molecule.yml today - nothing. Just make necessary adjustments to your create / destroy / etc playbooks so they get inventory from any place you like. I completely agree that there is a lot of complexity around how to use molecule for running tests and this complexity has been created in part by the fact that proper examples and documentation are missing. But that would be very hard to resolve this situation by adding more complexity and creating any standard is a complex endeavour. ---
**Author:** ![Jeff\_Pullen](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jeff_pullen/32/5318_2.png) [@Jeff\_Pullen](https://forum.ansible.com/u/Jeff_Pullen)\ **Post date:** [July 21, 2026, 8:08pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/4 "2026-07-21T20:08:19Z")
@kks Great feedback and points. I just want to address your final point to clarify my position. If the specifics of my proposal are adding more complexity than that is not intentional and something that I would want to iron out / eliminate. My goal isn’t really to add on, but rather standardize around a “happy path” that will meet the needs of most automation devs (YAML). Except for the molecule enhancement to skip the one task import\_playbook, everything else works “as-is” today. Its just leaning into a particular standard that users can reference and defend their decisions with. In fact the majority of the specifics are exactly what we have for examples in different places but never assembled into a single comprehensive package that automation devs can easily find. Worse, some of the docs conflict because they are addressing the other Ansible Dev (Python) group (for example using /tests/integration/targets). Your suggestion from 2023 of just having stand alone collections for the molecule playbooks/roles for importing may be the better answer. I checked last night and only 20 out of 100 collections bundled with ‘ansible’ have any roles included. Making the create/destroy content may not be all that difficult, but it is still extra work the maintainers of those existing collections may not want. ---
**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\ **Post date:** [July 31, 2026, 1:06pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/5 "2026-07-31T13:06:28Z")
> [@kks](#): > > having explicit playbooks that have to be copied from one molecule scenario to another is a bad thing FWIW I use symlinks for this. ---
**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\ **Post date:** [July 31, 2026, 2:06pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/6 "2026-07-31T14:06:07Z")
> [@chris](#): > > FWIW I use symlinks for this. I use ansible collections for this. Playbook can be part of a collection. Molecule relies on playbooks. So I have separate molecule.\* collections with just molecule playbooks, that are invoked from create.yml, destroy.yml, converge.yml, etc. This allows for version management and portability. ---
**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\ **Post date:** [July 31, 2026, 2:49pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/7 "2026-07-31T14:49:31Z")
Sorry if my contribution to this thread has been off-topic, I’ve just reread the thread title and I guess it doesn’t have relevance for roles, I haven’t started using collections yet. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [August 31, 2026, 3:18pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/8 "2026-08-31T15:18:07Z")
Thanks @Jeff_Pullen, @kks and @chris for your replies in this thread. I want to provide my thoughts on the areas raised above. ### Scope: A dedicated post to split the role only discussion This post was to focus specifically on collection testing. Role only testing is a critical part of the Ansible content ecosystem, but it is a different problem with a different persona, YAML first rather than Python first. Mixing the two into one discussion makes the discussions in this post about collections more confusing. I’d like to propose that we move the role testing replies above into a separate post, dedicated to that topic. This will help ensure collection testing decisions do not taint role only concerns and vice versa. ### Molecule: Playbook copying between scenarios On the point about copying playbooks across scenarios, you don’t need too. A common playbook can live once and be imported into each scenario with the `ansible.builtin.import_playbook` module. Please see the examples below: - [Common playbook](https://github.com/ansible-collections/community.beszel/blob/main/extensions/molecule/common/create.yml). - Reused across scenarios: [Example 1](https://github.com/ansible-collections/community.beszel/blob/main/extensions/molecule/agent_default/create.yml#L2-L3), [Example 2](https://github.com/ansible-collections/community.beszel/blob/main/extensions/molecule/agent_token/create.yml#L2-L3). The same goes for molecule’s `shared_state: true`. It’s not collection only, `molecule/default` at the root of a role repository works the same way as `extensions/molecule/default` inside a collection. `extensions/molecule` is a collection convention but not a hard requirement for this functionality. So the point in [#37](https://forum.ansible.com/t/unified-collection-testing-strategy-kick-off-landscape-overview/45799/37) that you end up in collection territory the moment you want supported testing is not strictly true IMO. ### Lack of documentation is the causing factor for several issues The more I look at these replies, the more I think a lot of this comes back to documentation, and the lack of it for role testing specifically. For example, the playbook copying problem above is likely a symptom of this documentation gap. The `import_playbook` pattern and `shared_state` in role mode are not documented anywhere (that I know of) currently, so when documented examples show a full copy of create/destroy per scenario, authors copy. When search returns the `driver:`/`platforms:` style, authors follow that. So, I think a real action item here for us is to focus on documentation for Molecule and on [docs.ansible.com](http://docs.ansible.com) too for role testing. I feel like this would go a long way and help a lot. What do you think? ---
**Author:** ![Jeff\_Pullen](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jeff_pullen/32/5318_2.png) [@Jeff\_Pullen](https://forum.ansible.com/u/Jeff_Pullen)\ **Post date:** [August 31, 2026, 4:36pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/9 "2026-08-31T16:36:59Z")
+1 Yes, splitting these two use-cases / personas would help a lot. The documentation is also a big part of it. Even when it does exist, there isn’t a good name or distinction between developing on the Python side vs the YAML side. Developing Ansible means different things to different people. If you go searching the internet for answers you’re more likely to land on the Python side of the documentation, even though I would wager there are many many times more people looking for the YAML docs. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 1, 2026, 10:48am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/10 "2026-09-01T10:48:55Z")
I’ve moved the original post and related responses into this new post for continued discussion. I think the three Molecule documentation areas we should focus on is: - [Using](https://docs.ansible.com/projects/molecule/getting-started-playbooks/) - [Examples](https://docs.ansible.com/projects/molecule/examples/docker/) - [Guides](https://docs.ansible.com/projects/molecule/guides/custom-image/) The contents in [Using](https://docs.ansible.com/projects/molecule/getting-started-playbooks/) reads like a guide to me, as it’s using `ansible-creator` - Maybe we could re-organize / consolidate these areas so it doesn’t feel so fragmented / scattered? Furthermore, we could look to add a “Role Testing” section to the Using area too. 🤔 ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 3, 2026, 8:14am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/11 "2026-09-03T08:14:59Z")
Made some progress here: [docs: add explicit testing entrypoints by dbrennand · Pull Request #4691 · ansible/molecule · GitHub](https://github.com/ansible/molecule/pull/4691) Added a “Choose your path” page which explains which guide to use depending on the type of content being created. Also added a “Test a role” guide too which uses the Ansible native configuration using the `containers.podman` collection. Please review if you’re interested 🙂 ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 8, 2026, 7:44pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/12 "2026-09-08T19:44:55Z")
[chore(docs): User Pathways and Role Getting Started Guide by dbrennand · Pull Request #4691 · ansible/molecule · GitHub](https://github.com/ansible/molecule/pull/4691) has merged and the new docs are live! 🙂 - [Choose your path - Ansible Molecule](https://docs.ansible.com/projects/molecule/getting-started/) - [Test a role - Ansible Molecule](https://docs.ansible.com/projects/molecule/getting-started-roles/) ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 9, 2026, 7:16am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/13 "2026-09-09T07:16:16Z")
I’m working on the next edit for documenting how to use `shared_state` to re-use playbooks in the `default` scenario for create and destroy sequences, when testing a standalone role. So in the same page as [Test a role - Ansible Molecule](https://docs.ansible.com/projects/molecule/getting-started-roles/) 🙂 ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 9, 2026, 8:13am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/14 "2026-09-09T08:13:39Z")
[chore: document shared state for standalone role testing by dbrennand · Pull Request #4695 · ansible/molecule · GitHub](https://github.com/ansible/molecule/pull/4695) Here is is 🙂 ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 9, 2026, 1:00pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/15 "2026-09-09T13:00:05Z")
[chore: document shared state for standalone role testing by dbrennand · Pull Request #4695 · ansible/molecule · GitHub](https://github.com/ansible/molecule/pull/4695) is merged now 🎉 🚢 Next is to update the same document to add an example for re-using playbooks across scenarios via the `import_playbook` module. ---
**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\ **Post date:** [September 9, 2026, 1:13pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/16 "2026-09-09T13:13:24Z")
I hope you do not mind me asking. What if there are two `reverse1` and `reverse2` scenarions (or more), In what order they will be executed? As state is shared it matters. When I execute one scenario will default run automatically? With destroy sequence? What if I want to have `reverse1` and `reverse2` scenarions to share state and scenarios `another1` and `another2` share another state? How can I do that? ---
**Author:** ![Jeff\_Pullen](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jeff_pullen/32/5318_2.png) [@Jeff\_Pullen](https://forum.ansible.com/u/Jeff_Pullen)\ **Post date:** [September 11, 2026, 6:36pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/17 "2026-09-11T18:36:54Z")
I like the idea of shared\_state. The challenge is that it is very different than the non-shared state way of doing things and the additional controls needed for it haven’t been implemented yet. To your question @kks, “groups” with shared state like what you’re asking for was in the original proposal but haven’t been implemented. [RFE: Shared state between scenarios](https://github.com/ansible/molecule/issues/4001) It also hasn’t tackled the problem of infrastructure and scenario ‘prepare’ distinctions. [Shared state gets corrupted when running scenarios in parallel, flaking CI](https://github.com/ansible/molecule/issues/4666) > The decision that isn’t mine to make is **who runs `prepare`**. `prepare` is overloaded: there is infra-level preparation of the shared instances (belongs with the single provisioner, run once) and per-scenario preparation of a scenario’s own view (its own `prepare.yml` a real, used feature). Today `--workers` sidesteps the distinction by force-running `prepare` everywhere. A correct fix has to separate the two: run the owner’s infra `prepare` once, and still run each scenario’s own `prepare` in its worker. Like I said, I like the idea of shared\_state, but we need some consensus on how it needs to look / work so that those extra controls can get added. The extra bits I can think of are ordering, grouping and per-scenario prepare and cleanup. ---
**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\ **Post date:** [September 14, 2026, 12:52pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/18 "2026-09-14T12:52:48Z")
I do not like idea of shared state, I like idea of shared infrastructure for several molecule scenarios. I think this is what is actually needed, but somehow we ended up with shared state. ---
**Author:** ![Jeff\_Pullen](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jeff_pullen/32/5318_2.png) [@Jeff\_Pullen](https://forum.ansible.com/u/Jeff_Pullen)\ **Post date:** [September 14, 2026, 3:01pm UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/19 "2026-09-14T15:01:29Z")
@kks well said, and more accurate to what I was trying to say. I was thinking of the flag to enable that shared infrastructure but it is named after the thing that keeps causing issues. I’ve been prototyping out a fairly significant change in the parallelism handling in Molecule recently. That effort started because the file and state sharing currently implemented has issues and is flaky. Its a big enough change that I’m planning on posting the proposal here on the forums in the next couple days for discussion. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [September 16, 2026, 7:38am UTC](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251/20 "2026-09-16T07:38:32Z")
> [@dbrennand](#): > > Next is to update the same document to add an example for re-using playbooks across scenarios via the `import_playbook` module. As I was looking to make this change, I noticed that there already is a guide for sharing playbooks across scenarios: [Sharing - Ansible Molecule](https://docs.ansible.com/projects/molecule/guides/sharing/) [Next page](https://forum.ansible.com/t/should-automation-developers-be-starting-with-role-only-collections/46251.md?page=2)