-
Notifications
You must be signed in to change notification settings - Fork 32
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
🐛 Unmanaged Terraform Variables are being unset #221
Comments
I know that the request might be a little bit difficult due to the following code only having access to its current state and the remote state: Ideally and CRD modification you would calculate a diff to know which variables were managed to clean up, or you might have some sort of internal storage mechanism to get the true diff between the previous state and the current state. Other simpler solutions that are less ideal that would solve my use case is a variable whitelist/blacklist to tell the operator what to manage, or even if it is just the ability to disable variable deletion all together. |
I think that's a feature not a bug, e.g.: if someone goes and messes up the variables you probably want the source of truth to be the CRD and not what someone might've changed in the UI by mistake. It's a common thing for the IaC world, is there a scenario for this being the case? There could be a parameter to define the strategy when drift is detected:
It should be straightforward to implement the solution, but understanding the requirements and expected/common patterns might be more complex. Maybe variable sets are a better option for such scenarios with different groups of variables. |
Generally I would say this is expected behavior. If a consumer is defining variables in the CRD this is the source of truth. If there is a need for variables to be enforced or have precedence this is something that was recently added to project based variable sets. This allows overrides to be applied by an administrator. Varsets are also independent of the workspace. |
I also have a use case here: I'm a Terragrunt user, and my current terragrunt setup provides a number of "standard" variables that people writing modules in my org can use for standardization. I have Terragrunt provision the workspaces then write a In general, I think this issue should be seen as a feature request for the TFE provider: We can't use the TFE provider to manage a workspace if TFC will go mess with it behind the scene and create drift. Providing a simple switch at the project and workspace level to override this behaviour would help. |
I do agree, if the Workspace CRD is managing a variable and someone manually changes it in TFC, it should get reverted. You should not be able to mess with a managed variable. My main idea here is: If the operator in managing a variable, manage it. If it is not managing it, leave it alone. If a variable is being managed, and then it's then removed from the Workspace CRD, it should be removed from TFC. This should be opt in functionality. |
Operator Version, Kind and Kubernetes Version
YAML Manifest File
# Copy-paste your YAML manifest here
Output Log
Output of relevant
kubectl
commandsSteps To Reproduce
Expected Behavior
What should have happened?
Variables that the Workspaces does not manage should not be modified / removed.
Actual Behavior
What actually happened?
The additional variable is deleted
Additional Context
This messes up the ability to have advanced configuration outside of the scope of the operator. Hopefully this issue gets resolved ASAP as I think it is a very important workflow to support.
References
Community Note
The text was updated successfully, but these errors were encountered: