-
-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance README to take advantage of terraform.tf
#46
Conversation
I added a destroy procedure. Using this module this way works very smoothly. Very nice architecture! |
I was just thinking the other day of doing something like this, I didn't know such functionality was already in place just not documented! However I'm wondering since it is so far undocumented can we make the following changes before this goes "public":
I would be happy to submit some PR for same changes in other repos if that helps, I don't remember seeing any of them advertise this approach either. |
This is an interesting approach! |
pretty sure you will have to set force_destroy to true before doing the final apply since the bucket is versioned |
Yes, I encountered that last time I did |
Sorry we haven’t been able to review this yet. We’ve been slammed with new projects. Has anyone else had a chance to test this out? |
No rush, @osterman. In fact, I will change this to WIP because I still want to check into the issues I mentioned in my last comment. |
terraform.tf
terraform.tf
@jmcgeheeiv even though the file is auto-generated I think it should be committed: if there is a change in the tf state module, or you make a change in input values, that you didn't realize would affect it, you will be able to see the change with git diff. Whereas without having committed it, you will only see what the plan tells you has changed, there will be no source to check for diff to help understand cause of change. Also is there any disadvantage? If a timestamp or other attribute in the generated file changed at every apply, that would be a good reason to gitignore it, but that's not the case. |
@schollii, in my most recent pass through the workflow I have made these changes:
Shall I implement these changes in the documentation? |
I gather this will work on v0.16.0? Pretty sure I had issues with 0.17.0 (#47). It seems like it's only the docs that are changing. I believe the workflow is this:
However I cannot verify that right now, but if you don't do that, then during terraform destroy you will get an error that the bucket has contents. After I deleted manually from AWS console a couple weeks ago, the destroy worked. |
@jmcgeheeiv I have verified the workflow and documented at #44 (comment) since PR's are harder to find. HTH. |
@jmcgeheeiv Definitely like the idea of getting this merged. I personally didn't know about this functionality and it sounds much preferred! Weighing in on a couple things:
Happy to get this PR approved, merged, and cut for you as soon as you and @schollii suss out the final changes you want to make to the README. Thanks gents! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. FWIW I use this in my backend-aws.tf (the file that uses the tfstate_backend module):
terraform_backend_config_file_name = "backend.tf"
terraform_backend_config_file_path = var.tf_state_is_remote ? "." : ""
force_destroy = ! var.tf_state_is_remote
then in my settings.auto.tfvars
I just define tf_state_is_remote
to be true or false. You just have to remember when you toggle between true and false to do a terraform init
. Then the apply will actually remove or create the backend.tf, pretty cool. But I think this is too complicated to explain in the readme.
To be honest Hashicorp should do this automatically, ie it should be possible to tell the s3 backend block what bucket etc to create and it should create and use it, so we wouldn't have to go through this rigmarole.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jmcgeheeiv I think that looks great! 👍
Since this is a collab with @schollii, I'll let him weigh in too before merging.
Thanks gents!
terraform.tf
terraform.tf
Today I had an opportunity to destroy a deployment, and I found an error in my destroy proceedure. I also added @schollii as a contributor.
Today I had an opportunity to destroy a deployment, and I found an error in my destroy proceedure. I also added @schollii as a contributor.
Today I had an opportunity to destroy a deployment, and I found an error in my destroy procedure (wrong value for I also added @schollii as a contributor. I hope you do not mind. If this bothers you, I can remove you from my fork and nobody will be the wiser. |
/rebuild-readme |
@jmcgeheeiv Sorry to do it to ya, but it looks like there are some merge conflicts. Mind fixing and we'll get this merged? |
definition file. Note that when `terraform_backend_config_file_path` is | ||
empty (the default), no file is created. | ||
|
||
1. `terraform init`. This downloads Terraform modules and providers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why all steps are numbered 1
? :)
I see it was like that before, but maybe now is a good time to fix that.
force_destroy = true | ||
} | ||
``` | ||
1. `terraform apply -target module.terraform_state_backend -auto-approve`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all steps are numbered as 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @jmcgeheeiv
please see comments
@aknysh markdown doesn't require sequence of numbers just first one must be '1'. See https://www.markdownguide.org/basic-syntax/#ordered-lists. However the readme is understandable without rendering if we use sequence of numbers. For small lists it's manageable, so I'm in favour of fixing. |
IMO 1s are preferable, since you dont need to reorder them if you add an item in the middle of the list |
ah yes, the user will see it as an unordered list, it's just in the code itself we have |
They will see it as an ordered list
|
|
@aknysh Did you mean to close this? I would think we would still want to get this merged. Mind if I reopen? |
oh sorry, clicked the wrong button, reopening |
/test all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good and we've hashed it out plently. Let's ship it!
@jmcgeheeiv @schollii Thanks for the contributions and wading through the updates! This is just a docs update, but still... Released as 0.18.1. |
what
terraform.tf
to the usage instructionswhy
terraform.tf
, which is actually quite brilliant functionalityreferences