-
Notifications
You must be signed in to change notification settings - Fork 90
Absolute paths in Statefile #19
Comments
is this related? External provider stores full path to command in state file causing thrash when executing on different machines - that issue was closed as a |
Hi @so0k! Sorry for this limitation. This is indeed a general problem, caused by the fact that providers currently don't have access to a base directory to relative-ize stored paths against. The current working directory isn't suitable, because Terraform supports running against configurations elsewhere. We do have plans to fix it, and that issue you referred to is one record of that, though I think there isn't currently a single issue capturing the broader problem. (It's on the team's radar, nonetheless.) With that said, I think there is a more localized bug here that we may be able to fix more easily to mitigate this issue in the short term: the expected behavior of a resource during refresh is for it to detect when the resource has been deleted outside (or in this case, has never existed on this machine in the first place) and flag that in the state so the resource can be re-created on the next run. Interestingly there is already code trying to handle this: // If the output doesn't exist, mark the resource for creation.
if _, err := os.Stat(destinationDir); os.IsNotExist(err) {
d.SetId("")
return nil
} It seems that for some reason this initial This particular issue aside, it's worth noting that in general local disk resources ( Terraform's architecture is primarily design around working with remote resources that shared for all users, with these local-disk resources provided for reasons of pragmatism. We may be able to improve the situation in the future -- for example, by using relative paths as we're discussing in this issue -- but it may be the case that resources that exist only on local disk are fundamentally incompatible with a shared remote state strategy and so some of these caveats may be very difficult to totally resolve within Terraform's current assumptions. We've heard reports of people using these resources in environments where Terraform is run in a controlled, remote environment... either on a shared remote system (which many people log into to run Terraform, or which runs Terraform via some sort of job automation system) or on systems that have a shared network filesystem mounted at a common path. This strategy is of course not workable for everyone, but within the current constraints it's the most robust way to make use of these resources. |
Hi folks, I don't think that this is an issue with the output directory not being found, it seems to me to be a problem with the input directory not being found due to the modules being in a different location. The error is just ambiguous due to the message in generateDirHash, I think it's the source directory due to the lstat being within the I've hit the same problem but through a different method, mine was due to using an updated version of the source module where the the modules within had been moved around. This meant that the hashed folder names in I'm not sure the best way to resolve this, but happy to try and raise a PR with some guidance. Should we check the existence of the source directory before attempting to hash, and mark for deletion from state if it doesn't exist? Is blanking the id enough for that, or does it need to be done differently? It's essentially an orphaned module in some ways, how is this handled elsewhere in other providers? Perhaps even |
No update on this one for so a long time? It is really a show stopper working with Terraform in a team. If anyone would tell me a workaround I would highly appreciate that. At the moment I'm removing the relevant parts in the state and generate new ones |
@apparentlymart any thoughts on my assessment of the above? |
A potential workaround: instead of
You may be able to do something like this, dropping the absolute path:
This is not super portable because the path is now relative to where |
Any updates on this issue? It currently blocks us from executing terraform from multiple sources |
The "local_file" resource also stores absolute path in a state file but works fine. Any updates with "template_dir" resource? |
... I wasted 10+ hours on that. The problem was so nested and I searched everywhere for the wrong paths, nut no match. Sure... remote state... just there during execution. |
When the source directory can't be found during a Read, it isn't meaningful to try to hash it and compare the hashes. Instead we should mark it dirty and continue to the Create step, where we will load the source templates based on the current module location instead of the plan contents. Fixes hashicorp#19
Output from
template
andlocal
providers store absolute path in statefile.This causes issues when using remote state and working in a team
Perhaps this is a known issue, please point me to related tickets or suggested workarounds as I was unable to find any so far.
Terraform Version
Affected Resource(s)
Please list the resources as a list, for example:
template_dir
Terraform Configuration Files
Debug Output
module.my_module.template_dir.configs: 1 error(s) occurred: * module.my_module.template_dir.configs: template_dir.configs: could not generate output checksum: lstat /Users/path/to/root/project/.terraform/modules/0a870bfa99885a552018aa68a1aac335/resources/configs: no such file or directory
Expected Behavior
Relative paths should be stored in statefile instead of Absolute paths
Actual Behavior
Absolute paths are stored in statefile and cause
lstat
errors onterraform refresh
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform init
both laptopsterraform apply
terraform refresh
The text was updated successfully, but these errors were encountered: