Hi
We are encouraged to create re-usable modules to build our infrastructure. But this turns out do be difficult once it comes to cross module dependencies.
Here is my use case.
I have these re-usable modules in an infrastructure modules repository:
module PlatformAPI
- has a APIGateway REST API
- has a APIGateway REST API Deployment
module LambdaRestEndpoint
- has a Lambda function
- has APIGateway REST Resources
And I want to use them in my live infrastructure:
Live Production Module
module "PlatformAPI" {
source = "git::[email protected]:xxx/infrastructure-modules.git//PlatformAPI"
}
module "LambdaRestEndpoint" {
source = "git::[email protected]:xxx/infrastructure-modules.git//LambdaRestEndpoint"
}
To make this work the following order should be achieved through cross module dependencies:
PlatformAPI > APIGateway REST APILambdaRestEndpoint > Lambda and REST ResourcesPlatformAPI > APIGateway REST API DeploymentSo basically the question is, how can a resource in one module can depend on a resource in another module if both of these modules don't know about each other?
This could be achieved elegantly with depends_on ["${var.ReadyToDeploy"]!
But unfortunately it is not possible to depend on input variables :(
Any suggestions? How is this supposed to work?
Hi @BerndWessels,
While you can't use a variable in "depends_on" you can use the variable itself which creates the dependency. If you don't have anywhere at all to use the variable, you can put in a null_resource and depend on that.
As for explicit inter-nodule dependencies, we're tracking that feature request in #10462.
@jbardin Thanks for the response.
Unfortunately that doesn't solve the main issue here, which is that we want to have resources in modules depend on resources in other modules - rather than just having modules depend on other modules.
As in my example above, to be able to have a re-usable module that encapsulates an APIGateway REST API and the corresponding APIGateway REST API Deployment and allowing other re-usable modules to provide REST API Resources to that REST API there must be a way to only make the APIGateway REST API Deployment dependent on the elsewhere defined REST API Resources.
A null_resource would not solve this problem.
Basically at the moment re-usable modules are limited to sets of resources that all depend on the same conditions - rather than each resource being able to depend on an injected condition.
Hi @BerndWessels,
Sure you can, albeit a little convoluted since you can't reference them directly, but the dependency path of an example moduleA and moduleB imported into root would look like:
moduleA.resourceA -> moduleA.outputA -> root -> moduleB.varB -> moduleB.resourceB
If you don't actually have a dependency in the configuration (i.e. there's no way to reference varB in resourceB), but need to force one with depends_on, that's where you can use the null_resource to give you a fake resource to target with depends_on.
Not only is depends_on rarely needed, but modules themselves are meant to be opaque, only exposing their outputs and variables, so targeting individual resources in a module isn't really feasible. Any enhancement that could be done in this areas can be further discussed in the referenced feature request.
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.
Most helpful comment
Hi @BerndWessels,
Sure you can, albeit a little convoluted since you can't reference them directly, but the dependency path of an example moduleA and moduleB imported into root would look like:
If you don't actually have a dependency in the configuration (i.e. there's no way to reference varB in resourceB), but need to force one with
depends_on, that's where you can use thenull_resourceto give you a fake resource to target withdepends_on.Not only is
depends_onrarely needed, but modules themselves are meant to be opaque, only exposing their outputs and variables, so targeting individual resources in a module isn't really feasible. Any enhancement that could be done in this areas can be further discussed in the referenced feature request.