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
Provide a way to trigger a re-provision of a resource #3193
Comments
Yeah this makes sense. We should support the common workflow of iterating on provisioners, and this feature seems like a relatively simple way to do it. Tagged. |
In certain cases it's possible to "fake" this using resource "aws_instance" "foo" {
// ...
}
resource "null_resource" "baz" {
connection {
user = "ubuntu"
private_key = "..."
host = "${aws_instance.foo.private_ip}"
}
provisioner "remote-exec" {
// ... etc
}
} With this in place, one can taint It's also possible to add a |
As per @apparentlymart's suggestion, here're my use-case details: I'm using Salt (in a masterless configuration) to provision a node at runtime with a few Currently, when I commit a change to my server's configuration or need to install new software I have to destroy the whole infrastructure and then apply the new plan. It doesn't matter if what I want to change is just a single line, in |
@pierrebonbon Wouldn't it make more sense, in this case, to use a master_ful_ Salt setup and the |
+1 on this. I use chef to provision all of my vms, and occasionally, the provision step will fail, which ultimately means that terraform will list the resource as tainted and will need to destroy and re-create it. A huge time waster. |
Absolutely. I understand the resources should be immutabile, but providing a solution for debugging and development purposes would be exteremely useful. |
Hi, I implemented data "http" "example" {
url = "https://checkpoint-api.hashicorp.com/v1/check/terraform"
# Optional request headers
request_headers {
"Accept" = "application/json"
}
}
resource "aws_instance" "ec2" {
# ...
}
resource "null_resource" "ec2-provisioner" {
triggers {
version = "${data.http.example.body}"
}
provisioner "remote-exec" {
connection {
# ...
}
inline = [
"ansible-playbook -i inventory playbook.yml --extra-vars 'foo=bar'",
]
}
} So, at the end Terraform will trigger Ansible only when metadata at Or for "development mode" you could use |
@sethvargo Why was this closed? |
+Failure Scenarios Guide
I still believe a |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
In an ideal world, provisioners are inherent to the immutable resource (AMI), and changing a provisioner would mean simply replacing the AMI entirely.
While this is certainly the most ideal scenario, there exists a much more common scenario where there is a desire to provision (or re-provision) one or more instances. This is especially helpful for development/iteration where waiting for an entire cluster to taint and recreate itself is time consuming and not an ideal workflow.
Notes:
terraform provision aws_instance.web.*
)I would be happy to flush out the API a bit more, but I wanted to open a ticket for early discussion before going too far.
/cc @phinze @catsby
The text was updated successfully, but these errors were encountered: