ansible-collections
Validate compatibility with ansible-core 2.19
Copied from ansible-community/ansible-build-data#538
ansible-core has implemented an extensive rewrite of templating and error handling as part of the data tagging feature coming in core-2.19. You can find information about this change in that PR description, as well as in the core 2.19 porting guide.
Please read background and testing requests, which details where you can file potential bugs.
Collections that are part of the Ansible community package MUST test against ansible-core 2.19 to ensure they continue to work with the updated core. Collections which are not compatible with ansible-core 2.19 will be removed from Ansible 12. You can choose to test against the stable-2.19 branch, the devel branch, the milestone branch, or the pre-release/released versions of ansible-core 2.19 available on Pypi.
This should be an ongoing verification/check until the release of core 2.19 to ensure compatibility with any bugfixes or changes that happen until then.
You can find advice from fellow maintainers at Making a collection compatible with data tagging, and we welcome your additions to that forum topic.
Note: You are not required to implement data tagging as part of this request, though we do recommend you consider where it can improve the quality of your collection. This issue is focused on ensuring you have verified your collection works with ansible-core 2.19 in order to remain included in the Ansible 12 community package.
We ask that you resolve any problems and link those PRs to this issue. If you do not find any problems with your integration/unit testing, please provide that comment and a pointer to your test results before closing this issue as done.
You can reach out on the Ansible forum for more help or discussion.
Sorry for the noise - I used the wrong collection list for the Ansible 12 package. I'll leave this issue open since this collection is still actively maintained and the information may be helpful as you test for a future release.
Since this collection has been re-included in Ansible 12, this is still relevant. #695 (or something equivalent) should be processed ASAP.
Felix,
I appreciate your fervor around 2.19. Unless you want to do it I do not have the bandwidth because fixing the actual modules are of a more pressing need. Once these are done I will prioritize 2.19 testing. Again 2.19 is buggy as hell so pressing this seems something not to be focused on rather than making sure the collection actually works.
Again 2.19 is buggy as hell so pressing this seems something not to be focused on rather than making sure the collection actually works.
That's a pretty strong statement. I'm not aware that ansible-core 2.19 is "buggy as hell", and to be honest, I haven't seen any indication showing that. If you have evidence for that statement, please provide it.
Igoring that, testing against ansible-core 2.19 should be one of the highest priority right now, to assess whether there are serious problems with the changes in ansible-core 2.19 or not. Simply not testing is not acceptable. By requesting cancellation of the removal, you implicitly promised to stick to the Ansible inclusion requirements. So please fulfill your side of the re-inclusion and make sure that testing against ansible-core 2.19 happens in CI, so it is clear whether it passes or fails.
Lord look at any internet board. There is a reason it is the first version to be in technology preview ever for core in the downstream. https://www.reddit.com/r/ansible/comments/1m7zv8w/ansiblecore_219_breaking_networking_modules/ . https://access.redhat.com/articles/7128367 , https://www.google.com/search?q=issues+with+core+2.19&oq=issues+with+core+2.19&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg80gEIMzY5MGowajSoAgCwAgE&sourceid=chrome&ie=UTF-8
With this being said we are working on it, but if the testing fails we are not going to spend many cycles troubleshooting and focus on the product. We will let you know the outcome.
Also , i do not quite think you remember me from Configmgmtboootcmp. Where in this documentation for inclusion does it call out ansible core 2.19 as a requirement. I went through it and I had AI go through it and we both did not find anything .
Correct me if I am wrong all we have to state is what version of core we support/tested on.
I get that if we want to be inlcuded in the latest community package we need the latest community versions.
Lord look at any internet board.
I do that, and I haven't really seen much that's actually bugs in ansible-core 2.19. That's why I ask.
There is a reason it is the first version to be in technology preview ever for core in the downstream.
That's Red Hat internal, so I don't know why that is. My guess is that it's because of many breaking changes and bugs in (RH maintained) collections, but not because of bugs in ansible-core 2.19.
https://www.reddit.com/r/ansible/comments/1m7zv8w/ansiblecore_219_breaking_networking_modules/
This is about bugs in networking collections and in particular ansible.netcommon. Quite a few of these bugs have been reported months (!) ago, and nothing has been done by the collection maintainers. We created issues in April (!) in all collections included in Ansible (like this issue we're in here!) that collections should check for compatibitiliy. The ansible.netcommon maintainers decided to ignore that, even though ansible.netcommon uses quite a few internals of ansible-core and is thus very suspective to breaks. Which then happened. And was reported in early May. And was ignored. So this is a lot, in particular it was totally avoidable, but it's definitely not a bug in ansible-core 2.19.
. https://access.redhat.com/articles/7128367
I don't see anything on bugs in ansible-core 2.19 here.
, https://www.google.com/search?q=issues+with+core+2.19&oq=issues+with+core+2.19&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg80gEIMzY5MGowajSoAgCwAgE&sourceid=chrome&ie=UTF-8
I don't see anything on bugs in ansible-core 2.19 here either, but more on problems with ansible.netcommon and other network collections.
With this being said we are working on it, but if the testing fails we are not going to spend many cycles troubleshooting and focus on the product. We will let you know the outcome.
Also , i do not quite think you remember me from Configmgmtboootcmp.
I do remember you, but I'm not sure how this relates to this thread.
Where in this documentation for inclusion does it call out ansible core 2.19 as a requirement. I went through it and I had AI go through it and we both did not find anything .
Look at section "CI Testing" (https://docs.ansible.com/ansible/latest/community/collection_contributors/collection_requirements.html#ci-testing). There it says You MUST run the ansible-test sanity command from the latest stable ansible-base/ansible-core branch. and You MUST run CI against each of the “major versions” (2.14, 2.16, 2.17, etc) of ansible-core that the collection supports. (Usually the HEAD of the stable-xxx branches.). The inclusion document right now does not say that you have to support the latest stable ansible-core release, since that is so obvious (this whole document is about the Ansible community package!) that nobody so far saw a need to explicitly mention that.
Correct me if I am wrong all we have to state is what version of core we support/tested on.
The collection claims to support ansible-core 2.19 as well: https://github.com/ansible-collections/google.cloud/blob/master/meta/runtime.yml#L2
I get that if we want to be inlcuded in the latest community package we need the latest community versions.
Yes, and that's what you asked for in https://forum.ansible.com/t/vote-ended-on-2025-07-21-collection-removal-google-cloud/8609/10.
We have implemented 2.19 testing across the board and is currently only failing on 4 modules. We are working to fix said modules to be in 100% compliance.