Remove or deprecate community.general.terraform

[gravesm]

Summary

With the release of the supported cloud.terraform collection, we wanted to propose removing or deprecating the terraform module in community.general. cloud.terraform.terraform was written to be backwards compatible with it.

[felixfontein]

The module in community.general has regular contributions, see

• https://github.com/ansible-collections/community.general/commits/main/plugins/modules/terraform.py (changes after removal of flatmapping)
• https://github.com/ansible-collections/community.general/commits/f84a9bf932890c4770c4b765240fb66d98c4d43b/plugins/modules/cloud/misc/terraform.py (changes before removal of flatmapping)
• https://github.com/ansible-collections/community.general/pull/5893

What happens to all these community contributions? Are some covered, others not? I.e. to which version is there actual compatibility? And what's the general policy for cloud.terraform, how easy will it be for community contributors to get new features in?

Also cloud.terraform is not part of the Ansible distribution, which means that removing it from c.g without adding cloud.terraform to Ansible is breaking all folks currently using the c.g module via the ansible package.

[tima]

@felixfontein I'll stick to your questions about the management of this content. @mgraves can to anything else I don't cover sufficiently here.

What happens to all these community contributions?

cloud.terraform started from terraform module and module utilities code as of November 7, 2022 here. From there a number of known issues as of that November 7 date where addressed. I need to check with some of the developers for specifically which ones.

More recent ones will need to get redirected over there to be reviewed for applicability. Backwards compatibility iin the operation and interface was a key objective in 1.0 of the collection so chances they translate are high.

Are some covered, others not? I.e. to which version is there actual compatibility?

Are you referring to the Terraform CLI? The cloud.terraform collection is following HashiCorp's support and end of life policies of the Terraform CLI in its testing. Older versions are best effort.

And what's the general policy for cloud.terraform, how easy will it be for community contributors to get new features in?

We'll review any contributions that are made and consider if they are in the scope of the collection's purpose and any outstanding roadmap items.

Also cloud.terraform is not part of the Ansible distribution, which means that removing it from c.g without adding cloud.terraform to Ansible is breaking all folks currently using the c.g module via the ansible package.

Good point. This is something we want to address and would want to see cloud.terraform get included in future ansible releases. Any links to that process would be appreciated.

[briantist]

Are some covered, others not? I.e. to which version is there actual compatibility?

Are you referring to the Terraform CLI? The cloud.terraform collection is following HashiCorp's support and end of life policies of the Terraform CLI in its testing. Older versions are best effort.

I believe this in reference to the assertion that cloud.terraform.terraform is backwards-compatible to community.general.terraform.

Since both are live and changing, and yours is based on a single specific version, the question of "compatibility" is important.

Also cloud.terraform is not part of the Ansible distribution, which means that removing it from c.g without adding cloud.terraform to Ansible is breaking all folks currently using the c.g module via the ansible package.

Good point. This is something we want to address and would want to see cloud.terraform get included in future ansible releases. Any links to that process would be appreciated.

There's a repository with instructions and such here: https://github.com/ansible-collections/ansible-inclusion

I definitely recommend checking out the inclusion checklist because even if you decide not to apply for inclusion, those things can really improve your collection :)

But I would also have some pause removing a working, active plugin from an ansible-package-included collection for the sake of pointing folks at a plugin that is not included in the package. If cloud.terraform is included (necessarily meeting the criteria for inclusion), then I would be much more inclined to redirect.

[gravesm]

What happens to all these community contributions? Are some covered, others not? I.e. to which version is there actual compatibility?

The commit history for the community.general.terraform module has been preserved in the cloud.terraform repo, so it's possible to see where the two diverge. There have been two small commits since the split (https://github.com/ansible-collections/community.general/commit/fc2b1aac4aca701f3e87706266ac2e32a905d9fe and https://github.com/ansible-collections/community.general/commit/44172ddaa6130d2441954da54da0ea70caf41521), both of which should be trivial to add to cloud.terraform.

From what I can tell, the changes proposed in https://github.com/ansible-collections/community.general/pull/5893 have already been implemented in cloud.terraform. The only difference I can see is that the PR adds plan_file to the module return.

I definitely recommend checking out the inclusion checklist

Looking over the checklist there's nothing that jumps out as being a problem that couldn't be easily addressed. The one exception I will point out is that the cloud.terraform collection has specifically been written to support python 3.8+ and ansible-core 2.13+

[maxamillion]

+1 to deprecate and later remove from the Ansible distribution, but leave it up on Galaxy for posterity and holdouts who want to freeze on the old content

[russoz]

+1 for deprecating and later removing

[Andersson007]

+1 to deprecate and later remove from the Ansible distribution, but leave it up on Galaxy for posterity and holdouts who want to freeze on the old content

+1

[mariolenz]

I also tend to +1 for deprecating and later removing

[felixfontein]

Do I understand you all correctly that by removing the module from c.g without adding redirects, you want to burn the short module name terraform and annoy all current users of the module?

[briantist]

Do I understand you all correctly that by removing the module from c.g without adding redirects, you want to burn the short module name terraform and annoy all current users of the module?

Well, I did not vote for that just yet, but I suppose we should decide on whether we intend short names to be sacred and preserved at all costs, or whether they should eventually be removed when their time is up.

This should probably be a new topic... my quick thoughts are that we should seek to preserve them for as long as they make sense, but probably not go too far out of our way to make them continue working when the lineage is not so clear anymore.

This case looks like a bit of an in-between since the "new" one intends to be a drop-in, but I think it's sort of straightforward in that it simply is not the same module anymore, and so if we are removing the module it points to, we should also remove the short name.

[felixfontein]

This topic still hasn't been decided, which is not surprising since cloud.terraform is not part of Ansible, and we haven't decided on #167 yet.

[felixfontein]

Someone created a PR to deprecate the module: https://github.com/ansible-collections/community.general/pull/7319

Unfortunately we still haven't concluded this discussion, resp. the related discussion in #167.

[felixfontein]

Ref: https://github.com/ansible-collections/community.general/issues/6317#issuecomment-1506656335 (no idea whether that's true or not.)

[mariolenz]

@gravesm Please close this issue if done, or open a new forum topic and then close the issue with a pointer to the new discussion: Community-topics: Archiving the repo

[Andersson007]

Whoever wants please re-open the topic on the forum, closing, thanks everyone!