peter-dolkens
commented
3 years ago Have been testing this more - have reproduced this where the id is changing between each apply.
Relevant terraform:
resource "octopusdeploy_variable" "mongo_password_readonly" {
name = "MONGO_PASSWORD_READONLY"
description = ""
type = "Sensitive"
owner_id = var.octopusdeploy_library_variable_sets.managed_mongo.id
is_editable = true
is_sensitive = true
scope {
tenant_tags = [ "Partner/${var.partner}" ]
actions = []
channels = []
environments = [ local.octopus_environment ]
machines = []
roles = []
}
sensitive_value = module.keyvault_mongo_password_readonly.keyvault_value
}
This resource has been applied to the stack, and then Octopus has been updated to the following "initial state":
First terraform run - the changes in the preview are expected, but notice the ID changes between the preview, and the modification complete
# octopusdeploy_variable.mongo_password_readonly will be updated in-place
~ resource "octopusdeploy_variable" "mongo_password_readonly" {
id = "0a1c8bd7-3613-4f86-a8cd-9f4235285775"
is_editable = true
is_sensitive = true
name = "MONGO_PASSWORD_READONLY"
owner_id = "LibraryVariableSets-463"
sensitive_value = (sensitive value)
type = "Sensitive"
~ scope {
actions = []
channels = []
~ environments = [
"Environments-22",
- "Environments-24",
]
machines = []
~ roles = [
- "classic-api",
]
~ tenant_tags = [
+ "Partner/tnz",
]
}
}
...
octopusdeploy_variable.mongo_password_readonly: Modifying... [id=0a1c8bd7-3613-4f86-a8cd-9f4235285775]
octopusdeploy_variable.mongo_password_readonly: Modifications complete after 1s [id=00004727-4113-cd73-58d9-669fb8a4322b]Second terraform run - at this stage, we don't expect any changes, but the ID has changed between this run and the previous run. It now reflects the ID reported in the modifications complete log from the previous run. Notice that once again, the ID changes between the apply preview, and the modification complete
octopusdeploy_variable.mongo_password_readonly: Refreshing state... [id=00004727-4113-cd73-58d9-669fb8a4322b]
...
# octopusdeploy_variable.mongo_password_readonly will be updated in-place
~ resource "octopusdeploy_variable" "mongo_password_readonly" {
id = "00004727-4113-cd73-58d9-669fb8a4322b"
is_editable = true
is_sensitive = true
name = "MONGO_PASSWORD_READONLY"
owner_id = "LibraryVariableSets-463"
sensitive_value = (sensitive value)
type = "Sensitive"
~ scope {
actions = []
channels = []
environments = [
"Environments-22",
]
machines = []
roles = []
~ tenant_tags = [
+ "Partner/tnz",
]
}
}
...
octopusdeploy_variable.mongo_password_readonly: Modifying... [id=00004727-4113-cd73-58d9-669fb8a4322b]
octopusdeploy_variable.mongo_password_readonly: Modifications complete after 1s [id=0a1c8bd7-3613-4f86-a8cd-9f4235285775]Third terraform run - once again, the refresh matches the previous modifications complete - which is the ID from the first apply - but no other changes are detected.
octopusdeploy_variable.mongo_password_readonly: Refreshing state... [id=0a1c8bd7-3613-4f86-a8cd-9f4235285775]
Final Octopus State:
Based on this final state, it would appear that the refresh and modified steps aren't properly obeying the ID, and are instead just filtering on an exact match of environment + variable name, with no checking of any other relevant scopes (or at least - not the tenant tags)
johnsimons
FinnianDempsey
tomer-ds
twerthi
garkenxian
zentron
Describe the bug When using the
octopusdeploy_variableresource, in particular with scopes (tags/environments) - the initial provision of the variable works fine, but subsequent apply actions can cause unrelated values to be overwritten.Have reproduced with Library Variable Sets - have not tested with Project Variables.
Steps to reproduce
MYVARand give it a value that is scoped to an environment, e.g.DEV, AND a tenant tag, e.g.Sample/tag1MYVARand give it a value that is scoped to a different environment, e.g.TEST, and the same tenant tag, e.g.Sample/tag1MYVARusing terraform, and give it a different scope again, e.g.STAGEandSample/tag1Expected behavior I would expect the octopus state to track the exact value that I provisioned based on the variable's ID field. Alternatively, tracking the value based on an exact-match of all scope values would be acceptable.
Logs and other supporting information
Initial Provision:
Subsequent Plan
Screenshots If applicable, add screenshots to help explain your problem.
Environment and versions:
0.13.70.7.42