fix: resource_docker_service tmpfs mounts #563 #570
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
terraform schemas can only work with int type which is either int32 or int64 equivalent depending on architecture, but the Docker lib expects an int64 for the size_bytes. Previously, the code assumed that the terraform schema would return an int64, which lead to provider crashes.
values are now being converted between int64 and int to handle this. The downside is possible value truncation: resources managed by Terraform can't have tmpfs size_bytes greater than just under 2 GiB (2147483647 byes by golang spec), which can lead to false information if the physical service has been modified to a tmfs size_bytes greater than that outside of terraform, because the int64->int conversion will possibly truncate that on go implementations where int is equivalent to int32.
As long as the limitiation of only TypeInt being available in the schema (and not e.g. TypeInt64) there will be no clean solution to this. An improvement could be to switch to either TypeFloat (53 bits of accuracy, still with the issue, but much less likely to impact in real life, it's 8TiB) or TypeString and convert the numbers between string representations. Both options exceed my Go capabilities though, I think.