Hey there,
I’ve written a PR to add a resource for importing snapshots from S3 in to an EBS volume. Part of this PR is a very small disk image which is uploaded to S3. To keep it small and inline with the test, I’ve gzip’d the disk and base64 encoded it. It comes out to about a tweets worth of data:
H4sIAAAAAAACA0vOz0tNLsmsYGBgYGJgZIACJgZ1789hZUn5FQxsDIzhmUbZMHEEzSIIJJj///+QlV1rMXFVnLzHwteXYmWDDfYxjIIhA5IrigsSi4pT/0MBRJSNAZoWGBkUGBj+//9SNhpSo2AUDD+AyPOjYESW/6P1/4gGAAvDpVcACgAA
That is a 512 byte disk. As part of the test, I base64 decode, ungzip, re-base64, and pass that string to the s3 object resource. I think this decode / decompress / encode process can’t really fail: it is entirely “static”, but execution is delayed to runtime. Because of this, the error checking for this pipeline uses panic.
Here is the PR: `aws_ebs_snapshot_import`: init resource by grahamc · Pull Request #16373 · hashicorp/terraform-provider-aws · GitHub
I’m concerned the red “X” on the PR makes it less likely to be reviewed, but since I’m not much of a Go programmer I’m not sure the right way to handle this in the context of creating the test content.
Any advice for me? I’d like to do everything I can to make this mergeable, so the NixOS project can use this resource to keep its AMIs fresh.
Thanks,
Graham Christensen