Skip to content
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

Add support for provisioners to modules #1240

Closed
radeksimko opened this issue Mar 18, 2015 · 7 comments
Closed

Add support for provisioners to modules #1240

radeksimko opened this issue Mar 18, 2015 · 7 comments
Labels
core enhancement thinking waiting-response An issue/pull request is waiting for a response from the community

Comments

@radeksimko
Copy link
Member

It is possible to use provisioners inside the module's code, but in case of local-exec, I'd personally discourage people from doing so (depending on what they're trying to do obviously).

I think it's hard to guess for the module's author what platform that local system will be etc. etc.

I can imagine the implementation could be as simple as this:

module "my_rds_instance" {
  source = "github.com/terraform-community-modules/tf_aws_rds"

  rds_instance_name = "${var.rds_instance_name}"
  rds_allocated_storage = "${var.rds_allocated_storage}"
  rds_engine_type = "${var.rds_engine_type}"
  rds_engine_version = "${var.rds_engine_version}"
  database_name = "${var.database_name}"
  database_user = "${var.database_user}"
  database_password = "${var.database_password}"
  rds_security_group_id = "${var.rds_security_group_id}"
  db_parameter_group = "${var.db_parameter_group}"

  provisioner "local-exec" {
    command = "echo 'export DB_HOST=http://${self.instance_endpoint}' > ./env/db-host.sh"
  }
}
@joescii
Copy link

joescii commented Sep 11, 2015

+1

2 similar comments
@eppdot
Copy link

eppdot commented Feb 16, 2016

+1

@wr0ngway
Copy link

+1

@catsby catsby added thinking waiting-response An issue/pull request is waiting for a response from the community labels Nov 8, 2016
@catsby
Copy link
Contributor

catsby commented Nov 8, 2016

Interesting idea, I wonder, do you think null_resource is a viable alternative here?

Or the template_file?

@mitchellh
Copy link
Contributor

I agree with @catsby that the null resource + depends_on referencing modules (new in 0.8) is the way to go here.

The biggest complication here is: how do we know when a module is new? Do we just do it the first time a module completely applies? What if resources are added/removed to a module? Do we do it whenever dependent resources in the module recreate? etc.

I'm not saying those are unsolvable problems by any means, but I think we have a ways to go in core land before we can look into this (such as splitting provisioners out into their own graph nodes). In the mean time, there is a great workaround with null_resource depending on a module or triggered by module outputs.

@aleclarson
Copy link

aleclarson commented Sep 27, 2017

Is there documentation for null_resource triggering when a module is created? (not sure if that's the correct terminology here)

I'm trying to remote_exec on an Openstack resource that's created in a module.

module "server" {
  source="./openstack"
}

resource "null_resource" "something" {
  triggers {
    # What goes here?
  }
  provisioner "remote_exec" {
    inline = [
      "echo Hello world"
    ]
  }
}

edit: Looks like depends_on is what I'm looking for. Sorry! #1178

@ghost
Copy link

ghost commented Apr 7, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core enhancement thinking waiting-response An issue/pull request is waiting for a response from the community
Projects
None yet
Development

No branches or pull requests

7 participants