With the lack of approval and maintenance on google.cloud has there been a desire to make a new community.google_cloud collection? There are tons of PR’s to that original repo to fix issues but the original maintainers are no longer maintaining that repo and are unresponsive. There obviously is a desire and need as it’s an extremely common repo and many do automate against Google Cloud. I’m just curious if this is even possible. Telling people to use Terraform (as seen in some of the commits) is not a valid suggestion/answer when this is Ansible, and the use of Ansible is often different than Terraform.
There is (or let’s say: has been) a community.google collection but we’ve removed it from Ansible 9 because it looked unmaintained, too.
At the end of the day, we need someone to maintain the collection. No matter if it’s a resurrected community.google or a new community.google_cloud or any other collection.
To make a long story short, if there’s nobody volunteering to maintain such a collection there won’t be any.
community.google was the left-over of the Google related modules/plugins in Ansible 2.9 that didn’t go to google.cloud (i.e. which nobody wanted to have). That might explain why it was dead even before google.cloud died 
Forking google.cloud as community.google_cloud or something like that should be fine. Maybe it’s even possible to take over google.cloud, though that name might be reserved for “official” Google content, which a community version probably won’t be. Maybe @gundalow / the community team know more about that, or will at least know whom to ask
I personally agree with @mariolenz that maintaining a collection is quite an amount of work (especially for one which needs a lot of work done, like google.cloud), so we need folks who want to step up to that and who can promise to keep it doing at least for some time. (I guess theoretically one person would be enough, but more than one decreases the chance of maintainer burnout.)
I guess we can use this thread to see if there are persons interesting in maintaining such a collection (or even “just” contributing - the more folks can help, the easier it usually gets).
Might make sense to announce this in The Bullhorn.
Good idea! I’ll mention in Bullhorn. I don’t know if this helps, but it’s worth a try.
Hmm, the collection doesn’t really look that unmaintained to me; there was a release in August (maybe triggered by New release? · Issue #642 · ansible-collections/google.cloud · GitHub).
Maybe it would be a good idea to start a discussion/issue in the collection’s repository first to figure out what’s going on? (I wasn’t able to find any such discussion.) Maybe the maintainer (there seems to be a single one) is simply time contrained and would appreciate help reviewing / triaging. In that case forking would make no sense.
Does anyone know whether SirGitsalot is active in the forum?
We can’t modify the autogenerated outputs I don’t believe.
It’s there anybody that’s interested in helping with this collection?
@gundalow I guess it’s not possible to simply take ownership of google.cloud because Google would object? I mean, it’s “their” namespace, isn’t it?
BTW Do you know if SirGitsalot has an account here in the forum? If not, I think this a little bit problematic now that we’re moving more and more communication to the forum.
That could be one option, though maybe we rename/redirect the repo & collection.
I’m meeting Google in a few weeks.
Is there anybody that’s interested in helping out with the Google collection?
Does the autogenerator for google.cloud not even exist anymore? Remove Ansible autogeneration Code by rambleraptor · Pull Request #7161 · GoogleCloudPlatform/magic-modules · GitHub
The google.cloud collection is ok for creating/deleting resources, but not designed to reach the desired end state from any initial state, which is the bare minimum I expect from an Ansible module unless it declares otherwise.
I would dust off my Google cloud account to review/test changes to community.google, which has less tech debt imo, and was also mainly authored by Google, just abandoned in favor of autogenerated modules.
Agreed, there should be a sense of idempotency, supporting creation/deletion/updating of a resource. But it appears you are right the auto-generation is gone, and that’s probably why the repo is a bit of a mess.
For me I’ve had so many issues with the modules over the past year I’ve had to resort to ansible.builtin.url and when statements to perform what a single module should be able to do.
@shertel @ericsysmin Are you suggesting that community.google might be the better way to go?
If the auto generation no longer works, and that’s how the repo was built, it may be. But from a professional perspective I don’t understand why Google wants to abandon google.cloud. We should wait for after your meeting, as that could shine light on what the future should be/hold.
1 Like
Maybe just partially. The issue only affects google.cloud modules that manage mutable resources. Manually fixing all the affected modules seems like a large undertaking. Google could provide a programmatic way to update arbitrary resources if they wanted (AWS does, for their similar Cloud Control API service, which has been used to generate AWS modules in GitHub - ansible-collections/amazon.cloud: Ansible Collection for Amazon AWS' Cloud Control API), but I guess it’s a moot point if there’s no way to generate those modules anymore to automate the fix.
Any google.cloud non-module plugins, _info/_facts modules, or modules managing immutable resources wouldn’t be affected though.
The tests for the google.cloud modules just exercise creating/deleting/no modification, so adding the missing test coverage for modifying resources could be a good first step to assess what’s broken. (But this was also my feedback ~7y ago when they were first being developed…)