So CHEF-4502 just got merged to master last week and will be released
with 11.10.0 and was in the 11.10.0.rc.0 released yesterday (I just
updated the ticket correctly which was mistakenly listing it as 11.12.0).
That should mitigate at least a lot of the truncated downloads problem
(I think that it may mitigate all truncated downloads in the
remote_file resource
since we should be doing HTTP/1.1 and not using chunked encoding or
anything like that which would not have a Content-Length header, but i’ll
admit that’s getting into the weeds of HTTP further than my knowledge
goes). There’s also still the possibility of corrupted bit flipping in
the stream which a checksum would address (or the file being transferred
into RAM correctly but then having RAM->disk corruption or whatever due
to crappy RAM/MB/chipset/etc), but fixing CHEF-4502 should knock down
the probability of a corrupted download by an order of magnitude or so.
On 1/31/14 7:45 AM, Julian C. Dunn wrote:
Yes, I think this is currently a shortcoming in Chef.
So CHEF-4502 just got merged to master last week and will be released
with 11.10.0 and was in the 11.10.0.rc.0 released yesterday (I just
updated the ticket correctly which was mistakenly listing it as
11.12.0).
That should mitigate at least a lot of the truncated downloads problem
(I think that it may mitigate all truncated downloads in the
remote_file resource
since we should be doing HTTP/1.1 and not using chunked encoding or
anything like that which would not have a Content-Length header, but
i’ll
admit that’s getting into the weeds of HTTP further than my knowledge
goes). There’s also still the possibility of corrupted bit flipping
in the stream which a checksum would address (or the file being
transferred into RAM correctly but then having RAM->disk corruption or
whatever due to crappy RAM/MB/chipset/etc), but fixing CHEF-4502
should knock down the probability of a corrupted download by an order
of magnitude or so.