Open findmyname666 opened 1 year ago
Files identified in the description:
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
cc @m-yosefpor @rainerleber click here for bot help
@findmyname666 Thanks for your interest and contribution here. Late last year we released the cloud.terraform collection which brought over the code here in community.general and then enhanced and supplemented it with additional content. We are beginning the process of adding cloud.terraform to the Ansible distro and deprecating what is in community.general. All of the Ansible team at Red Hat's efforts will be going into that new collection going forward. I recommend bringing your ideas and contribution there for consideration.
@tima thx I didn't know about it. I will check it ;)
Summary
Hello all,
I was looking at implementation of terraform module recently. I have a few questions, ideas and proposals how to improve it going forward. I will use numbering order for the purpose of referencing if there will be some discussion:
I was thinking to add a new feature and I went through module code-base ... it was kinda hard for me to understand it and to add some new code there because of several if conditions which can change based on user's input. For that reason I would like to propose to rewrite it and use "object" representation in the code. From top of my head I would create separate classes for workspace manipulation + state and class for terraform execution. I'm willing to code some proposal in the upcoming weeks/months (based on the time) if you are OK with that. Additionally I could become the maintainer as well.
Features:
a) I'm used to use terragrunt/terraform combo for deployment of terraform code. Based on that I kinda missing possibility to decide if I want to apply a new changes (I'm aware of planned state). This could be achieved to first run
terraform plan
with colours, display it to user, ask for user input and continue based on it. This shouldn't be difficult because we run plan for apply either way in the current state. We could introduce a new argument calledauto
which isTrue
by default.b) I would benefit from the possibility to generate terraform providers based on the arguments passed to module. In real world scenario users often manage several modules. Providers needs to be specified in each module and upgrades are kinda pita. Managing providers versions from 1 place would be awesome.
.tf
files usehcl
configuration language and I'm not sure how difficult this would be but it is worth to explore.c) We could run
plan
also forabsent
state which isn't case in the current state. This could be achieved by runningterraform plan
with argument-destroy
:d) We could ran
apply
with-json
argument in auto mode. I kinda expect it will provided more "machine" readable output. Additional benefit is that we could take outputs directly fromapply
and we don't have to runterraform output
at the end. Some high-level examples:3) Questions to documentation / code.
a ) I'm kinda not sure if running init pose any risk. I'm using it very often and I never hit any issue. I mean it will not provision new infrastructure by default. Link to init documentation.
b) In a code you are creating
plan_file
as a temporary file when it isn't provided for apply (link). However the path to plan file isn't printed to user and the file isn't cleaned up at the end. This can technically reveal some information about infrastructure to any user - TMP directory can be read by any user in linux OS.Looking forward to your replies.
Issue Type
Feature Idea
Component Name
terraform
Additional Information
No response
Code of Conduct