Repository navigation
hetzner: fix disk sizes before NetBox 4.1 and handle API errors - #626
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Two fixes for the Hetzner source, one commit each.
Disk sizes on NetBox 3.7 to 4.0
The volume size was always multiplied by 1024. Before 4.1 NetBox stores virtual disk sizes in GB (#413), so a 10 GB volume ended up as 10240 GB. The size is now converted to MB only on NetBox 4.1+, like the vmware and aws sources do. Nothing changes on 4.1+, and disks written with the wrong size on an older NetBox get fixed on the next run.
Bad token / API not reachable
init_successfulwas alwaysTrueand the first API call happened inapply(), so a revoked token or an unreachable API ended the whole run with a bare tracebackand none of the other sources got synced either.
__init__()now makes one small request (GET /servers?per_page=1). If it fails, the error is logged and the source is skipped, the same way vmware and ovirt handle a failed login. The other sources still sync, and netbox-sync disables pruning for that run, so the objects of the Hetzner source stay in NetBox (tagged as orphaned until the token works again).apply()(the server list or a volume lookup), the Hetzner error is logged and the run stops like it does for the aws source ("No NetBox writes or pruning will be performed."). Skipping the source at that point isn't safe: pruning is already on, so its objects would be marked orphaned and eventually deleted.The
if not tokencheck inapply()is gone:api_tokenis mandatory, so the config parser already exits on an empty value.Tests are in the new
tests/test_hetzner_source.py; they feed hcloud with responses shaped like the Hetzner API (401 for an unknown token). Also checked end to end against a stub Hetzner API and a fake NetBox 4.0.11 and 4.3.0.