we publish when significant changes have been made. As you mentioned, only updates related to CI etc have been made. So what is the point? Should we make publications … without changes? The collection is in use and works as it is. At the moment there is no effort to further expand api coverage and development as this is not our priority.
No response does not mean no reaction, but that action has been taken that is not visible to anyone. If you want a response, the committee should make it clear in the question that a response is required!
true/false is not a “feature” currently being worked on in the docs. Even in Ansible’s core modules, there are modules that still have a no/yes syntax. If that’s a reason to throw a working collection out of the community package, go for it…
I have a strong feeling that this “cleanup” of working and used collections will only lead to Ansible losing relevance.
“You can install collections manually”: → Yes, you can, but AFAIK there is no (for years) integrated update mechanism to update collections and roles. So you have to manually check for updates via more and more roles and collections… do we really think this is the way to go?
As far as I can tell, ngine_io.cloudstack works, and is in use and whenever I see a need, I try to find time to work on it but I am not sure if this fits your definition of “maintained”.
@resmo Thanks for the quick reply. You are totally correct, I don’t want to encurage any wasteful work.
If the collection works and ansible-test still passes against latest version, then the Collection is good, and should stay in the ansible community package. A stable collection may go a long time between updates.
This might not be a significant change, but it looks like an improvement that is lost to the users of your collection. At least to those who don’t install directly from GitHub. So it’s not only updates to the CI since the last release.
Anyway, I’ll take this from my list. Sorry for having bothered you.
If you see a problem there, maybe you should start a topic here on the forum to discuss this.
There are some violations of the inclusion criteria, but it should be pretty simple to address the issues.
“All CI tests MUST run regularly (nightly, or at least once per week)”
Tests have not run since May 28. This is due to GitHub automatically disabling scheduled workflows on inactive repositories. You can re-enable them manually when this happens.
“The results from the regular CI runs MUST be checked regularly.”
Integration tests have been failing for months. This is because of unsafe conditionals in some tests (for example here) which are broken by the fix for CVE-2023-5764. This condition should instead be written as pf.vm_name == cs_portforward_vm, avoiding the double interpolation.
These tests currently run against stable-2.14 and are passing for devel, you just need to update the CI config.
While it’s not an inclusion requirement, it would also be nice if you updated the versions of the CloudStack test container you run tests against; the newest version of CloudStack that’s being tested with your current config is four years old.