New collection: ravendb.ravendb

[TheGoldenPlatypus]

An Ansible collection for deploying, configuring, and managing RavenDB clusters on Linux-based environments.

Ansible Galaxy: https://galaxy.ansible.com/ui/repo/published/ravendb/ravendb/
GitHub: https://github.com/ravendb/ansible-collection-ravendb
Issues Tracker: https://issues.hibernatingrhinos.com/issues
GitHub Handles: @TheGoldenPlatypus @gregolsky @garayx @ppekrol
Is the collection part of Automation Hub: No
We meet Collection Requirements: Yes

[Andersson007]

@TheGoldenPlatypus hello, thanks for submitting the collection! Someone from @ansible-collections/steering-committee will take a look as soon as they have time. Please be patient, thanks

[Andersson007]

Make sure you really meet https://docs.ansible.com/ansible/devel/community/collection_contributors/collection_requirements.html, otherwise it can take longer.
You can use a short version of the requirements here: https://github.com/ansible-collections/ansible-inclusion/blob/main/collection_checklist.md for your convenience and then go to the main doc ^ if there are any questions.

[gundalow]

@TheGoldenPlatypus Thank you for this inclusion request.
Due to Red Hat Summit/Ansible Fest we are a bit short staffed this week and next, though this work has been added to our internal tracker, so we will get this sorted. Updates will be provided via this GitHub Discussion.

[TheGoldenPlatypus]

@Andersson007 @gundalow
Thanks for the updates. We’ll re-review the checklist and wait to hear back. Enjoy the Summit/Fest!

[epacific1]

Ansible Collections Checklist (short version)

For details about the following points, refer to the Collection Requirements.

Every comment should say whether the reviewer expects it to be addressed, or whether it's optional.

Note for reviewers: If you don't know how to check any of the points below, please ask maintainers of the collection you're reviewing or a Steering Committee member for clarifications in comments of corresponding inclusion discussion.

Public availability and communication:

• published on Ansible Galaxy with version 1.0.0 or later
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues
• have a public git repository
• releases of the collection are tagged in its repository

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
• follows the Ansible documentation standards and the style guide
• follows development conventions; as well as these other requirements:
  • modules satisfy the concept of idempotency
  • modules that only gather information are named <something>_info
  • modules that return ansible_facts are named <something>_facts and do not return non-facts
  • other modules must not allow querying information using specific state option values, or similar mechanisms (like state=get or state=query). These features should be moved to <something>_info or <something>_fact modules.
  • check_mode is supported in all _info and _facts modules
• supports all Python versions supported by all ansible-core versions its supports. If it does not, read the full guidelines to see if you qualify for an exception and document the unsupported Python versions in the collection README.md and in every module and plugin (or in doc fragments)
• only uses the allowed plugin types in the plugins/ directory
• has README.md
• FQCNs are used for all plugins and modules including ansible.builtin. for builtin ones from ansible-core in all their appearances in the documentation, examples, and return sections, and in extends_documentation_fragment:s.
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added (except cases when they were added in the very first release of the collection)
• public plugins, roles and playbooks do not use files outside of meta/, plugins/, roles/, and playbooks/

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the ansible package
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
• has changelog, preferably with changelogs/changelog.yaml
• collection repository should not contain any large objects (binaries) comparatively to the current Galaxy tarball size limit of 20 MB. For example, package installers for testing purposes shouldn't be added.
• collection repository should not contain any unnecessary files like, for example, temporary files. Temporary files should be added to .gitignore.

Tests:

Note for reviewers: If you don't know how to check the points below, please ask maintainers of the collection you're reviewing how you can do it.

• In most cases, CI is set up via GitHub Actions.
• Check .yml files in the .github/workflows directory. There must be at least the sanity section under jobs containing the ansible-test sanity command running against all supported ansible-core versions that must be also listed there, for example, - stable-2.15, - stable-2.16, - stable-2.17.
• Check workflow runs by clicking the Actions tab in the repository's page - you're interested in Scheduled runs, runs against release commits and runs against pull requests.
• If there are no workflows in the Actions tab, ask the collection maintainers how CI is implemented.

• passed ansible-test sanity
• if test/sanity/ignore*.txt exists, it MUST not contain error codes listed in the list of errors that must not be ignored
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
• all CI tests MUST run against every pull request
• all CI tests MUST run regularly (nightly, or at least once per week)
• sanity tests MUST run against a commit that releases the collection; if they don't pass, the collection won't be released

[Andersson007]

Ansible Collections Checklist (short version)

For details about the following points, refer to the Collection Requirements.

Every comment should say whether the reviewer expects it to be addressed, or whether it's optional.

Note for reviewers: If you don't know how to check any of the points below, please ask maintainers of the collection you're reviewing or a Steering Committee member for clarifications in comments of corresponding inclusion discussion.

Public availability and communication:

• published on Ansible Galaxy with version 1.0.0 or later
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues
  QUESTION: Should a ref from galaxy.yml point to the collection repo rather than to ravendb issue tracker?
• have a public git repository
• releases of the collection are tagged in its repository

Standards and documentation:

• adheres to semantic versioning
  SHOULD FIX: On https://github.com/ravendb/ansible-collection-ravendb/blob/main/CHANGELOG.md a link to the Ansible collections changelog format refers to 404
  RECOMMENDATION: Many collections are released using tooling from the releasing guidelines, please take a look
• follows licensing rules
• follows the Ansible documentation standards and the style guide
  MUST FIX: Add the attributes section with check_mode support information to every module that supports it
• follows development conventions; as well as these other requirements:
  • modules satisfy the concept of idempotency
  • modules that only gather information are named <something>_info
  • modules that return ansible_facts are named <something>_facts and do not return non-facts
  • other modules must not allow querying information using specific state option values, or similar mechanisms (like state=get or state=query). These features should be moved to <something>_info or <something>_fact modules.
  • check_mode is supported in all _info and _facts modules
• supports all Python versions supported by all ansible-core versions its supports. If it does not, read the full guidelines to see if you qualify for an exception and document the unsupported Python versions in the collection README.md and in every module and plugin (or in doc fragments)
  MUST FIX: the collection doesn't support all eligible Python versions (starting with stable-2.16). See the guidelines
• only uses the allowed plugin types in the plugins/ directory
• has README.md
• FQCNs are used for all plugins and modules including ansible.builtin. for builtin ones from ansible-core in all their appearances in the documentation, examples, and return sections, and in extends_documentation_fragment:s.
  SHOULD FIX: The modules use FQCNs, but as the collections also provide roles and playbook, i believe they should also use FQCNs (they don't)
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added (except cases when they were added in the very first release of the collection)
• public plugins, roles and playbooks do not use files outside of meta/, plugins/, roles/, and playbooks/
  SHOULD FIX: I didn't scrutinize the roles/playbooks, but make sure they do NOT use anything outside the directories, e.g. the ansible.cfg or the inventories directory I mentioned below. They imo must be removed

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the ansible package
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
• has changelog, preferably with changelogs/changelog.yaml
• collection repository should not contain any large objects (binaries) comparatively to the current Galaxy tarball size limit of 20 MB. For example, package installers for testing purposes shouldn't be added.
• collection repository should not contain any unnecessary files like, for example, temporary files. Temporary files should be added to .gitignore.
  MUST FIX ?: There's the ansible.cfg file and the inventories directory with some custom IP. I think it they should be removed

Tests:

Note for reviewers: If you don't know how to check the points below, please ask maintainers of the collection you're reviewing how you can do it.

• In most cases, CI is set up via GitHub Actions.
• Check .yml files in the .github/workflows directory. There must be at least the sanity section under jobs containing the ansible-test sanity command running against all supported ansible-core versions that must be also listed there, for example, - stable-2.15, - stable-2.16, - stable-2.17.
• Check workflow runs by clicking the Actions tab in the repository's page - you're interested in Scheduled runs, runs against release commits and runs against pull requests.
• If there are no workflows in the Actions tab, ask the collection maintainers how CI is implemented.

• passed ansible-test sanity
• if test/sanity/ignore*.txt exists, it MUST not contain error codes listed in the list of errors that must not be ignored
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
  MUST FIX: Add stable-2.18 to your test matrix.
  RECOMMENDATION: Add stable-2.19 and devel. You can remove stable-2.15 as it's EOL
• all CI tests MUST run against every pull request
• all CI tests MUST run regularly (nightly, or at least once per week)
• sanity tests MUST run against a commit that releases the collection; if they don't pass, the collection won't be released

[Andersson007]

@TheGoldenPlatypus hello, thanks for incorporating the feedback! Sorry for the delay, was on PTO

• On the Python versions, as you can see in the matrix, Python 2.7 is still supported on targets and I see only 3.* in your collection matrix.
• Also please take a quick look at this announcement

[TheGoldenPlatypus]

Thanks for the clarification, @Andersson007.
I've added Python 2.7 to our test matrix.

[Andersson007]

@TheGoldenPlatypus thanks, i've re-checked and marked almost all as OK
Oh, sorry, i copy-pasted the same link twice in the comment above. Here's a correct on https://forum.ansible.com/t/ansible-core-devel-and-milestone-bumped-to-2-20-0-dev0/43679 , please add testing against stable-2.19 to your matrix and then I'll approve the collection for inclusion. Thanks
UPDATE: Then please release the collection so that the changes will appear on Galaxy

[TheGoldenPlatypus]

@Andersson007 thanks, I went through everything you asked:
added testing against stable-2.19 and released the collection so the changes are now on Galaxy. Let me know if anything’s missing.

[Andersson007]

@TheGoldenPlatypus approved for inclusion! There's another SC review needed to get included, i'll ping them. Thanks

[traytorous]

Ansible Collections Checklist (short version)

For details about the following points, refer to the Collection Requirements.

Every comment should say whether the reviewer expects it to be addressed, or whether it's optional.

Note for reviewers: If you don't know how to check any of the points below, please ask maintainers of the collection you're reviewing or a Steering Committee member for clarifications in comments of corresponding inclusion discussion.

Public availability and communication:

• published on Ansible Galaxy with version 1.0.0 or later
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues
• have a public git repository
• releases of the collection are tagged in its repository

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
• follows the Ansible documentation standards and the style guide
• follows development conventions; as well as these other requirements:
  • modules satisfy the concept of idempotency
  • modules that only gather information are named <something>_info
  • modules that return ansible_facts are named <something>_facts and do not return non-facts
  • other modules must not allow querying information using specific state option values, or similar mechanisms (like state=get or state=query). These features should be moved to <something>_info or <something>_fact modules.
  • check_mode is supported in all _info and _facts modules
• supports all Python versions supported by all ansible-core versions its supports. If it does not, read the full guidelines to see if you qualify for an exception and document the unsupported Python versions in the collection README.md and in every module and plugin (or in doc fragments)
• only uses the allowed plugin types in the plugins/ directory
• has README.md
• FQCNs are used for all plugins and modules including ansible.builtin. for builtin ones from ansible-core in all their appearances in the documentation, examples, and return sections, and in extends_documentation_fragment:s.
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added (except cases when they were added in the very first release of the collection)
• public plugins, roles and playbooks do not use files outside of meta/, plugins/, roles/, and playbooks/

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the ansible package
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
• has changelog, preferably with changelogs/changelog.yaml
• collection repository should not contain any large objects (binaries) comparatively to the current Galaxy tarball size limit of 20 MB. For example, package installers for testing purposes shouldn't be added.
• collection repository should not contain any unnecessary files like, for example, temporary files. Temporary files should be added to .gitignore.

Tests:

Note for reviewers: If you don't know how to check the points below, please ask maintainers of the collection you're reviewing how you can do it.

• In most cases, CI is set up via GitHub Actions.
• Check .yml files in the .github/workflows directory. There must be at least the sanity section under jobs containing the ansible-test sanity command running against all supported ansible-core versions that must be also listed there, for example, - stable-2.15, - stable-2.16, - stable-2.17.
• Check workflow runs by clicking the Actions tab in the repository's page - you're interested in Scheduled runs, runs against release commits and runs against pull requests.
• If there are no workflows in the Actions tab, ask the collection maintainers how CI is implemented.

• passed ansible-test sanity
• if test/sanity/ignore*.txt exists, it MUST not contain error codes listed in the list of errors that must not be ignored
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
• all CI tests MUST run against every pull request
• all CI tests MUST run regularly (nightly, or at least once per week)
• sanity tests MUST run against a commit that releases the collection; if they don't pass, the collection won't be released

[Andersson007]

@ansible-collections/steering-committee : Second short review is needed here. i've conducted the first inclusion review and approved the collection.
Could anybody please do the second one by checking only the following points (or more if you wish):

• follows the Ansible documentation standards and the style guide
• follows development conventions; as well as these other requirements:
  • modules satisfy the concept of idempotency
  • modules that only gather information are named <something>_info
  • modules that return ansible_facts are named <something>_facts and do not return non-facts
  • other modules must not allow querying information using specific state option values, or similar mechanisms (like state=get or state=query). These features should be moved to <something>_info or <something>_fact modules.
  • check_mode is supported in all _info and _facts modules

@ansible-collections/steering-committee please conduct the review ^ and explicitly approve the collection.

[gundalow]

Approved

[Andersson007]

@TheGoldenPlatypus hey, i got feedback from another SC member:

• Recommendation: It would be good for the common options (URL, database_name, certification_path, ca_cert_path) to be moved to module_utils & doc_fragments, and then included in the modules.
  • As an example, see how the postgresql_alter_system imports some common options from plugins/doc_fragments/postgres.py
• Question: Does the module https://github.com/ravendb/ansible-collection-ravendb/blob/main/plugins/modules/node.py really work? Doesn't look like it imports the above options.
• The rest looks OK.

Could you please take a look?

[TheGoldenPlatypus]

hey @Andersson007,

Recommendation: It would be good for the common options (URL, database_name, certification_path, ca_cert_path) to be moved to module_utils & doc_fragments, and then included in the modules.
As an example, see how the [postgresql_alter_system](https://github.com/ansible-collections/community.postgresql/blob/765e12a2f739363aeedbf2698d9455da410e377c/plugins/modules/postgresql_alter_system.py#L85) imports some common options from plugins/doc_fragments/postgres.py

Done

---

Question: Does the module https://github.com/ravendb/ansible-collection-ravendb/blob/main/plugins/modules/node.py really work? Doesn't look like it imports the above options.

yes, the module works. The confusion was due to the argument structure.
previously, we had a nested node: dictionary, which looked like this:

- name: Join Node C as a Member
  ravendb.ravendb.node:
    node:    # <-- the nested dict was unnecessary and confusing
      tag: C
      url: "http://192.168.118.77:8080"
      leader_url: "http://192.168.117.90:8080"

I flattened the arguments to be top level, removing the node: wrapper.
now, the module call is simpler and clearer:

- name: Join Node C as a Member
  ravendb.ravendb.node:
      tag: C
      url: "http://192.168.118.77:8080"
      leader_url: "http://192.168.117.90:8080"

---

Please let me know if there are any more fixes needed. This time, I’ll wait with updating our collection on Galaxy until we have final approval, as I want to avoid bumping the collection version on every review

Thanks for your quick reviews!

[gundalow]

@TheGoldenPlatypus Thank you for ravendb/ansible-collection-ravendb#10
I'm happy for this collection to be included in the ansible package

[Andersson007]

@TheGoldenPlatypus i've created the inclusion topic https://forum.ansible.com/t/default-date-2025-08-04-collection-inclusion-include-ravendb-ravendb-in-the-ansible-community-package/44150, FYI

If no objections, the collection will get included next week, i.e. will appear in the next minor Ansible package release.
You might be also interested in requesting a forum tag.
Thanks

[mariolenz]

@TheGoldenPlatypus FYI I don't have any objections to include the collection, only about the suggested date when to do it. See my comment on the forum.

So it's possible that you have to wait until 12.1.0 (ETA 2025-08-19) to see it in the Ansible Community Package.

[TheGoldenPlatypus]

Hi everyone,
Thank you all for your trust and support in our collection. I'm happy to hear that it’s going to be included!

I've already published the updated version on the Galaxy platform.
No worries about the release date - please go ahead whenever you're ready.

Also, is there any documentation or guidance on what happens after inclusion?
Will the collection be forked, and how are future releases handled?

Thanks !

[mariolenz]

Also, is there any documentation or guidance on what happens after inclusion? Will the collection be forked, and how are future releases handled?

I'm not sure if we have any documentation on this. But we won't fork the collection, at least not to include it in the Ansible Community Package. Maybe someone of us will in order to work on it and open PRs, though. But that's the usual procedure on GitHub, isn't it, and doesn't have anything to do with the inclusion.

New releases you publish on galaxy should be included automatically in the next Ansible release. That is, if we don't stumble upon any collection inclusion requirement violation. In this case, we might restrict the version of your collection to an earlier one that looks OK.

Important: Ansible follows semantic versioning, and we require collections to follow this also. So we will not include a 2.x release of the collection in Ansible 12. But it should be included automatically it you publish it before we release 13.0.0b1 (no ETA yet).

I hope this answers your questions.

[felixfontein]

When looking at the tests, I saw that you're running ansible-test sanity --python xx instead of ansible-test sanity --docker. You really shouldn't do the former, but always the latter.

(Check out https://docs.ansible.com/ansible/devel/community/collection_contributors/collection_requirements.html#ci-testing.)

[gotmax23]

@TheGoldenPlatypus, looking at the CI configuration, I see that the integration tests and unit tests are only running with a single version of Ansible and Python, and notably, not running against ansible-core 2.19 which will be included in Ansible 12. It is a strict requirement that collections run CI tests against all versions of Ansible Core included in currently maintained versions of the ansible package (see the link @felixfontein included).

Many collections use ansible-test units and ansible-test integration along with the Ansible Test Github action or with https://ansible.readthedocs.io/projects/antsibull-nox/, but you should be able to set up a Github Actions matrix to pip install the appropriate ansible-core versions with your current approach, as well.

[TheGoldenPlatypus]

@felixfontein @gotmax23, I’m going to be super verbose here since we’ve got a bunch of Python and Ansible versions in play, plus some best practice stuff. Easy to get lost in it all, so heads up :)

I’ve updated our GH Actions CI to make Python / Ansible compatibility explicit, so we cover all supported combinations.

---

1. Sanity Tests

based on @felixfontein comment, I've changed the ansible-test sanity to run inside docker , not on the host Python.
so if I grasp things right - ansible-test in Docker automatically tests against all supported Python versions for that ansible-core release.
so I don't need to list every supported Python version in the job matrix for sanity. (the python-version in the matrix in only used to install the correct ansible-core before running ansible-test)

so for example - [Ansible Sanity Tests (3.12, stable-2.16] combination results in:

Running sanity test "compile" on Python 2.7
...
Running sanity test "compile" on Python 3.6
...
Running sanity test "compile" on Python 3.7
...
Running sanity test "compile" on Python 3.8
...
Running sanity test "compile" on Python 3.9
...
Running sanity test "compile" on Python 3.10
...
Running sanity test "compile" on Python 3.11
...
Running sanity test "compile" on Python 3.12

so according to our CI matrix

- python-version: "3.12"
  ansible-core: stable-2.16
- python-version: "3.12"
  ansible-core: stable-2.17
- python-version: "3.13"
  ansible-core: stable-2.18
- python-version: "3.13"
  ansible-core: stable-2.19
- python-version: "3.13"
  ansible-core: devel

the following combinations will be tested:

ansible-core	host python version	python versions tested inside docker
stable-2.16	3.12	2.7, 3.6–3.12
stable-2.17	3.12	3.10–3.12
stable-2.18	3.13	3.10–3.13
stable-2.19	3.13	3.11–3.13
devel	3.13	matches devel support

2. Integration + Unit Tests

for Molecule scenarios and unit tests things work differently:

molecule runs on the host Python, not in a ansible-test container. this means we must list all supported python versions for each ansible-core version in the matrix.

ansible-core	python versions
stable-2.16	3.10, 3.11, 3.12
stable-2.17	3.10, 3.11, 3.12
stable-2.18	3.11, 3.12, 3.13
stable-2.19	3.11, 3.12, 3.13
devel	3.12, 3.13

---

I’m fairly confident I’ve got full coverage here, but I wanted to lay out the details so we’re all on the same page. I’d love to hear your thoughts.

I dropped Python 2.7 for stable-2.16 in the integration tests because it doesn’t play well with Molecule, community.docker, and related dependencies, too many compatibility issues to make it worthwhile here.
However, the Python 2.7 x Ansible 2.16 combination remained intact.
I also haven’t had much time to dig into the Nox project yet, so maybe we can revisit that in a future iteration.

here’s the PR with the changes: link
and here an example run: link
Once you give me the green light, I’ll ask my superior to review and merge it. Thanks!

[TheGoldenPlatypus]

@gotmax23
I’ve addressed your review and wanted to summarize the changes.

first, I had to deal with the "Molecule + Ansible 2.19/devel conditional issue" : ansible-community/molecule-plugins#311
which break in Ansible >=2.19/devel.
To keep CI green for now, I added a temporary patch step in the workflow . This is a nasty workaround, but it’s isolated and will be removed once upstream fixes the plugin.

second, I rewrote parts of the role where our own tasks were failing for the same reason (when conditions returning a non-boolean value).
This only started breaking in newer ansible core releases (>=2.19) because Ansible recently made conditionals stricter : https://docs.ansible.com/ansible/devel//porting_guides/porting_guide_core_2.19.html#example-implicit-boolean-conversion.

so,
here’s the PR with the changes: link
and here an example run: link.

since this time I made some changes in the role itself , I'll wait for your green light to update our collection on galaxy.
thanks

[felixfontein]

I think everything should be addressed now.

[Andersson007]

@TheGoldenPlatypus it's been included https://forum.ansible.com/t/default-date-2025-08-04-collection-inclusion-include-ravendb-ravendb-in-the-ansible-community-package/44150/12.
Congrats and thanks everyone!

[TheGoldenPlatypus]

We’re excited to see our collection officially included in the Ansible community package.
Big thanks to everyone involved, we’ll make sure to keep it well maintained and regularly updated.

btw, will the collection be included in the next 11.x release? when is the next 11.x release planned?

[mariolenz]

when is the next 11.x release planned?

Probably September 9, but I won't promise anything.

BTW it looks like we won't include the collection in Ansible 12.0.0 but 12.1.0. I don't know when this will be. The situation with Ansible 12 is ... a little bit complicated.