-
Notifications
You must be signed in to change notification settings - Fork 3
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
[QT-601] Nest scenario step variables in eval context #107
Conversation
@@ -63,12 +63,12 @@ scenario "step_vars" { | |||
|
|||
output "module_default" { | |||
description = "a known value inherited through module defaults" | |||
value = step.infra_default.az | |||
value = step.infra_default.variables.az |
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.
Oh neat. I didn't know you could do this. To clarify, this is just taking the value that you're inputting into step infra_default
? I have been doing something like...
locals {
network_cluster = "e2e_cluster"
}
step "create_docker_network_cluster" {
module = module.docker_network
variables {
network_name = local.network_cluster
}
}
step "create_boundary" {
module = module.docker_boundary
depends_on = [
step.create_docker_network_cluster,
]
variables {
network_name = [local.network_cluster]
}
}
but I could change that to...
step "create_docker_network_cluster" {
module = module.docker_network
variables {
network_name = "e2e_cluster"
}
}
step "create_boundary" {
module = module.docker_boundary
depends_on = [
step.create_docker_network_cluster,
]
variables {
network_name = [step.create_docker_network_cluster.variables.network_name]
}
}
Is that correct?
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.
you can after this ships!
Previously we'd expose any know scenario step variables at the top-level of a steps entry in the eval context. This leads to problems if a Terraform module has both an input and output with the same name. Consider the following scenario: ```hcl module "cluster" { source = "./modules/cluster" } module "worker" { source = "./modules/worker" } variable "addr" { type = string default = "http://192.168.0.1" } scenario "boundary" { step "cluster" { module = module.cluster variables { addr = var.addr } } step "worker" { module = module.worker variables { upstream_addr = step.cluster.addr } } step "worker_downstream" { module = module.worker variables { upstream_addr = step.worker.upstream_addr } } } ``` We expect expect `step.cluster.addr` to be the known value of of `var.addr`. But what happens with step worker here is the problem. `step.worker.upstream_addr` should be module call to `step.cluster.addr` but because we've exposed `step.cluster.addr` in the eval context we don't do a module call, and instead inherit the value from `var.addr`. The same happens with `step.worker_downstream.upstream_addr`. Instead of being a module call to `step.worker.upstream_addr` we inherit the know value of `var.addr`. With this change that behavior is now default. If you wish to use the prior behavior (getting a steps known variables) you can access them with the `variables` key, e.g. `step.cluster.variables.addr`. - [x] The commit message includes an explanation of the changes - [x] Manual validation of the changes have been performed (if possible) - [x] New or modified code has requisite test coverage (if possible) - [x] I have performed a self-review of the changes - [x] I have made necessary changes and/or pull requests for documentation - [x] I have written useful comments in the code Signed-off-by: Ryan Cragun <[email protected]>
2737e91
to
fe66533
Compare
Previously we'd expose any know scenario step variables at the top-level
of a steps entry in the eval context. This leads to problems if a
Terraform module has both an input and output with the same name.
Consider the following scenario:
We expect expect
step.cluster.addr
to be the known value of ofvar.addr
. But what happens with step worker here is the problem.step.worker.upstream_addr
should be module call tostep.cluster.addr
but because we've exposed
step.cluster.addr
in the eval context wedon't do a module call, and instead inherit the value from
var.addr
.The same happens with
step.worker_downstream.upstream_addr
. Instead ofbeing a module call to
step.worker.upstream_addr
we inherit the knowvalue of
var.addr
.With this change that behavior is now default. If you wish to use the
prior behavior (getting a steps known variables) you can access them
with the
variables
key, e.g.step.cluster.variables.addr
.NOTE: this is technically a breaking change in behavior. We'll want to test all of Vault
before we release this. If we do run into issues we can modify scenarios to use the
variables option if they want old behavior.