config/module: storage path should be independent of system #1418
Conversation
|
These two args should change from |
|
Yep. |
|
Ok, I've grokked the |
|
Ok two questions:
Why weren't the paths portable? Seems like an MD5 of an absolute URL should result in a consistent hash?
I think you meant "no longer have" here yeah? So multiple instances of a module means it could be downloaded twice. |
|
That's right. The URL for file paths was specific to a system, so it wasn't portable. |
config/module: storage path should be independent of system
An md5 hash of the dst is used as the folder name on disk. In hashicorp#1418 this was altered to not be platform specific. The dst was changed from the source to a key based on the module path. This was done so that terraform push would work. This had the side affect that modules with the same source would result in multiple downloads. This was acknowledged in the original commit. This is a simple way to have the key be based on source again. Tested with terraform get and all works ok. With terraform get --update the update is done multiple times as if the 1:1 mapping was still in place.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
This is a really important change to make copying entire
.terraformdirectories work properly. Before, the hash in the.terraform/modulesfolder would be calculated based on the full URL of the source of the module. There are benefits to this:terraformimmediately notices.The downside is that the paths aren't portable at all, which conflicts with
terraform push. In this PR, I change the hash to be the hash of the "path" of the module: example "root.child.child2". This makes it portable, but makes it so that we have an exact 1:1 mapping of download of a module to folder. I don't think this optimization matters right now.I think the proper long term solution is to have some sort of "module.lock" file that does this mapping for us so the hash doesn't matter at all. But for a 0.4.1 I wanted to minimize what is touched.
@phinze: Would appreciate some thoughts here and a review.