## 1.1.0 (2025-05-10)
### Features
* smaller snapshots by zeroing disk first (#101) (fdfb284)
### Bug Fixes
* upload from local image generates broken command (#98) (420dcf9)
## 1.1.0 (2025-05-10)
### Features
* smaller snapshots by zeroing disk first (#101) (fdfb284)
### Bug Fixes
* upload from local image generates broken command (#98) (420dcf9)
The base image used requires ~0.42Gi. Even if the uploaded image is
smaller, those bytes are currently not overwritten and still part of the
stored snapshot.
By zeroing the root disk first, those unwanted bytes are removed and not
stored with the snapshot.
This has two benefits:
1. Snapshots are billed by their compressed (shown) size, so small
images are now a bit cheaper.
2. The time it takes to create a server from the snapshot scales with
the snapshot size, so smaller snapshots means the server can start more
quickly.
This reduces the size of an example Talos x86 image from 0.42Gi before,
to 0.2Gi afterwards. An example Flatcar image was 0.47Gi before, and
still has that size with this patch.
There are two ways to zero out the disk:
- `dd if=/dev/zero of=/dev/sda` actually writes zeroes to every block on
the device. This takes around a minute to do.
- `blkdiscard /dev/sda` talks to the disk direclty and instructs it to
discard all blocks. This only takes around 5 seconds.
As both have the same effect on image size, but `blkdiscard` is SO MUCH
faster, I have decided to use it.
Even though only small images benefit from this, this is now enabled by
default as the downside (5 second slower upload) does not justify
additional flags or options to enable/disable this.
Closes#96
While adding support for qcow2 images in #69 I broke support for local
images. Building a shell pipeline through string concatenation is not a
good idea...
The specific issue was fixed and I also moved building the shell
pipeline to a separate function and added unit tests for all cases, so
it should be easier to spot these issues in the future.
Closes#97
In #68 I reduced the general limits for the back off, thinking that it
would speed up the upload on average because it was retrying faster. But
because it was retrying faster, the 10 available retries were used up
before SSH became available.
The new 100 retries match the 3 minutes of total timeout that the
previous solution had, and should fix all issues.
In addition, I discovered that my implementation in
`hcloudimages/backoff.ExponentialBackoffWithLimit` has a bug where the
calculated offset could overflow before the limit was applied, resulting
in negative durations. I did not fix the issue because `hcloud-go`
provides such a method natively nowadays. Instead, I marked the method
as deprecated, to be removed in a later release.
Use `goreleaser` and `ko` to automatically build and publish container
images in the release workflow. The images are published to
`ghcr.io/apricote/hcloud-upload-image`.
Co-authored-by: Ilja Malachowski <malahovskiy.in@gmail.com>
The CLI depends on the lib, and to make sure that users who install
through `go install` use the correct version, we need to cut a release
for the lib first, bump in CLI and then release CLI.
It is now possible to upload qcow2 images. These images will be
converted to raw disk images on the cloud server.
In the CLI you can use the new `--format=qcow2` flag to upload qcow2
images. In the library you can set `UploadOptions.ImageFormat` to
`FormatQCOW2`.
Because of the underlying process, qcow2 images need to be written to a
file first. This limits their size to 960 MB at the moment. The CLI
automatically checks the file size (if possible) and shows a warning if
this limit would be triggered. The library accepts an input with the
file size and logs a warning if the limit would be triggered.
Closes#44
