Comments (9)
A potential workaround: instead of
source_dir = "${path.module}/resources/configs"
You may be able to do something like this, dropping the absolute path:
source_dir = "my-great-module/resources/configs"
This is not super portable because the path is now relative to where terraform
is executed, but it worked out ok for my use case.
from terraform-provider-template.
Any updates on this issue? It currently blocks us from executing terraform from multiple sources
from terraform-provider-template.
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 data
resource state is replaced on every refresh, but this issue relates to resource
for which refresh does a diff and errors out
from terraform-provider-template.
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 os.Stat
call is returning an error that isn't classified as a "does not exist" error. This is curious since the later error is pretty clearly a "no such file or directory" error resulting from a stat operation. It seems like there's a strange interaction to figure out here, to see why the above isn't working. If we can get to the bottom of that, you should be able to get past this error and have Terraform plan to create the directory from scratch as expected when running on a new machine.
This particular issue aside, it's worth noting that in general local disk resources (template_dir
and local_file
in particular) have some additional caveats compared to most providers unless the target is a shared filesystem, since although the state is remote, and the config is presumably in version control, these generated files would not exist on local disk for other users even if the paths were relative. For many use-cases this is okay, since just re-generating files for each new system is straightforward, but it does nonetheless lead to some state churn as the resource in question will get marked as deleted each time it's refreshed on a machine that doesn't have the files present.
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.
from terraform-provider-template.
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 .terraform/modules
directory.
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 .terraform/modules
were different due to them being in different places in the graph. So in my case terraform should mark them for deletion from the state (although I'd likely try and use state mv
on them to put them in the right place instead).
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 tarDir
should exit early and return an empty buffer if the directory doesn't exist?
from terraform-provider-template.
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
from terraform-provider-template.
@apparentlymart any thoughts on my assessment of the above?
from terraform-provider-template.
The "local_file" resource also stores absolute path in a state file but works fine. Any updates with "template_dir" resource?
from terraform-provider-template.
... 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.
from terraform-provider-template.
Related Issues (20)
- Template 2.0.0 tries to interpulate percent (%) signs followed by curly-braces {} HOT 3
- Breaking change in substitution in v2.0.0 HOT 1
- Extremely unprofessional backward incompatible release HOT 1
- The new 2.0.0 doesn't parse %${var} core HOT 6
- Make Terraform validate template_file on plan phase
- Feature request: Render variables in filenames in template_dir
- Template provider - Better error message at template parsing HOT 2
- Terraform template creating the wrong type of numbers HOT 5
- template_dir doesn't work on Terraform v0.12.4 HOT 2
- template_dir doesn't skip hidden files HOT 1
- [regression] provider-template fails rendering when template file has % in the content starting from v2.0.0 HOT 3
- go module uses invalid version HOT 4
- Passing Lists as Template Variables HOT 2
- template_dir can't handle subdirectories correctly on windows: open <filename>: The system cannot find the path specified.
- depends_on should wait for template_dir generation HOT 3
- Provider cannot be migrated to terraform-plugin-sdk as it uses `lang` pkg directly
- Terragrunt panic due to api body size. HOT 2
- Unsupported functions in template file HOT 1
- Changes from nearly a year ago not published
- Provider archived
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terraform-provider-template.