Investigate optimisation opportunities for workspaces w/ symlinks #1398
Comments
|
@briceburg Thank you for describing the tree with symlinks. We can try to reproduce this but based on some other issues I have filed before I can imagine symlinks generally causing issues, performance-related or not. I have transferred your comment here as the issue you commented on primarily focuses on different problem, which is processing that happens after file is opened. The optimisation there could help in your case but it doesn't target symlinks in any way, so it would be incidental if you see improvements, rather than intentional. Related: |
|
We have done some investigating in #1409 and have some ideas on how we can improve the performance when links are involved. It is however non-trivial, so while we still want to address this problem, we will have to weigh the complexity/effort against other work. For these reasons (to aid prioritisation): @briceburg would you mind describing your motivations in more detail? As far as I understand, you're dealing with repetition between different customers, apps and different environments. What I'm specifically curious about is what problems are symlinks solving for you, which modules cannot solve, or solve in a suboptimal way? On a separate note, I'm vaguely aware that symlinks are generally Unix concept and they may not translate well to Windows. How do you deal with this problem? Do you just assume/ensure that all users, CI systems etc. always run on Unix? |
|
Marking this issue as stale due to inactivity over the last 30 days. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label. Thank you for understanding. |
|
@radeksimko I am terribly sorry for my delayed response.
primarily our reliance on symlinks is to maintain DRYness when defining providers, common variables/locals, and other core bits of the root configuration. while we previously used workspaces to handle this, in practice it became cumbersome and less flexible than having separate root configurations per environment per google's advice. we do use modules in this root configuration as would be expected, e.g.; # foo-project/environments/production/main.tf
module "main" {
source = "../../modules/main"
...
}... but chose to use symlinks as a happy medium to stay DRY when switching from workspaces to using environment directories.
thankfully git properly handles symlinks and I believe Windows 10+ support is better (os x is fine) -- although you are correct in that we ensure our CI systems are containerized and or under a linux runner. |
|
Maybe I am wrong, but why not just let the language server open and parse symlinks when they match the |
|
Workspaces are an obvious footgun. Symlinks are a more robust solution. It would be appreciated if |
|
Indeed. Also because |
|
I'm in a similar situation, where I use a directory per state, but this causes some issues with the LSP. In We get several shared base configurations that are linked into many states. Then, for a given domain's environment, we link to the directory just above, so that all states have the base configurations and the domain configurations. In that way, the only actual non-link files in the environment directory are the backend configuration in versions.tf and the variables in terraform.tfvars. This works extremely well, except it make the LSP complain a bit and jumping to definitions doesn't work. I'm not sure what the actual solution could be though, because in the files actual location, the source paths are just not correct, and I don't see a way for the LSP to intuit where it should be looking. It doesn't know where the file could be potentially linked. However, it would be done with a comment directive like: module "core" {
# terraform-ls: source = "./module/domain-core"
source = "../modules/domain-core"
# ...
} |
Originally posted by @briceburg in #1375 (comment)
Ever since switching to a monolithic structure (where all terraform configurations under a single repo) the vs code extension has become unresponsive/unusable for me. even when using v0.31.5 of the language server.
Repo structure looks like;
The text was updated successfully, but these errors were encountered: