hetznercloud / packer-plugin-hcloud Goto Github PK

Please search the existing issues for relevant feature requests, and use the
reaction feature
(https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
to add upvotes to pre-existing requests.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

As of now, when I run packer build, the server gets ipv4 and ipv6 address both. I would like to avoid ipv4 here.

Use Case(s)

I'm hitting limit on my project where I cannot have more ipv4 addresses.

Could not create server: Primary IP limit exceeded (resource_limit_exceeded)

Independent of this as well I think it will be great if the project supports that.

Potential configuration

Potential References

Overview of the Issue

This is happening since yesterday i think, I'm getting this very frequently and sometimes when I invoke back to back I get the same message.

==> hcloud: Validating server types: cx41
==> hcloud: Validating snapshot name: packer-1718362350
==> hcloud: Creating temporary RSA SSH key for instance...
==> hcloud: Uploading temporary SSH key for instance...
==> hcloud: Creating server...
==> hcloud: Could not create server: error during placement (resource_unavailable, 6c4be35cf2e8ed9d)
==> hcloud: Deleting temporary SSH key...
Build 'hcloud' errored after 2 seconds 706 milliseconds: Could not create server: error during placement (resource_unavailable, 6c4be35cf2e8ed9d)

==> Wait completed after 2 seconds 706 milliseconds

==> Some builds didn't complete successfully and had errors:
--> hcloud: Could not create server: error during placement (resource_unavailable, 6c4be35cf2e8ed9d)

==> Builds finished but no artifacts were created.

sometimes this seems to go away after a while but I invoke packer build almost say more than 30 times in less than a hour in different projects using terminal multiplexer to do things. This all is wrapped around a make target.
It would be really helpful to me if we have more information than resource_unavailable here. What does it mean? I'm not able to understand the error message as well in this case.

Reproduction Steps

packer build against a packer config. (packer version is 1.9.5 MPL licensed)

Plugin and Packer version

packer version: v1.9.5
packer plugin hcloud version: 1.4.0

Simplified Packer Buildfile

If the file is longer than a few dozen lines, please include the URL to the
gist of the log or use the Github detailed
format
instead of posting it directly in the issue.

Operating system and Environment details

OS, Architecture, and any other information you can provide about the
environment.

Log Fragments and crash.log files

Include appropriate log fragments. If the log is longer than a few dozen lines,
please include the URL to the gist of the log or
use the Github detailed format instead of posting it directly in the issue.

Set the env var PACKER_LOG=1 for maximum log detail.

This is the same problem that the Scaleway builder had (hashicorp/packer#9839), for which I wrote a PR (hashicorp/packer#9840) that has been merged. In the same spirit, I would like to propose a PR also in this case.

Overview of the Issue

If you set the hcloud builder parameter snapshot_name to a fixed string, and you run Packer more than once, it will create multiple snapshots with the same name.
Note: it never creates "images", or, said in another way, user-created "images" (what then you would pass to Terraform) are always "snapshots".

Although these multiple snapshots are distinguished by the backend with a unique ID, for example:

$ hcloud image list | grep snapshot
ID       TYPE     NAME DESCRIPTION  ...  CREATED
49206576 snapshot -    banana       ...  Wed Sep 29 20:07:02 CEST 2021
49206827 snapshot -    banana       ...  Wed Sep 29 20:08:30 CEST 2021

from a Packer point of view, in my understanding this should not happen. I am used to the Packer AWS EC2 builder and rightly so it refuses to build an image if another one exists with the same name, see builder/amazon/common/step_pre_validate.go.

From my understanding, the current behavior (multiple images/snapshots with the same name) should happen only if the -force flag is specified to packer build.

Consider also that Hetzener Cloud makes you pay each snapshot based on the image size, and normally in Terraform you would refer to it with the "name" (so getting always the latest in the series), not with the unique ID.

From my point of view, this behavior is both error-prone and a waste of money: each time you run a packer build, you add to the bill :-)

Reproduction Steps

Run packer build at least twice:

$ packer build repro.pkr.hcl
$ packer build repro.pkr.hcl

Verify in the hetzner cloud console (or with the command-line tool hcloud image list that there are two snapshots with the same name.

Plugin and Packer version

Packer v1.7.4
hcloud plugin latest version v1.0.1

Simplified Packer Buildfile

packer {
  required_version = ">= 1.7.4"
  required_plugins {
    hcloud = {
      version = ">= 1.0.1"
      source  = "github.com/hashicorp/hcloud"
    }
  }
}

source "hcloud" "cfg" {
  # set token via env var HCLOUD_TOKEN
  image        = "debian-11"
  location     = "hel1"
  server_type  = "cx11"
  ssh_username = "root"
}

build {
  source "hcloud.cfg" {
    # Set the snapshot "description", what is visible in the UI and from the
    # CLI with `hcloud image list | grep snapshot`.
    # Note that user-created images don't have the field "name".
    snapshot_name = "banana"
    # We need this kludge to refer to the image from Terraform, since the field
    # "name" is empty. This is not needed to show the bug of the Packer plugin,
    # but I keep it because without it it cannot be used by Terraform.
    snapshot_labels = {
      "name" : "banana"
    }
  }
}

Operating system and Environment details

Doesn't apply.

Log Fragments and crash.log files

Doesn't apply.

Overview of the Issue

Packer with the Hetzner Cloud plugin is unable to connect to the server via SSH.

Reproduction Steps

env PACKER_LOG=1 packer build -debug .

Plugin and Packer version

v1.7.10

Simplified Packer Buildfile

packer {
  required_plugins {
    digitalocean = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/hcloud"
    }
  }
}

source "hcloud" "TEST" {
  image         = "centos-stream-9"
  location      = "fsn1"
  server_type   = "cpx21"
  ssh_username  = "root"
  snapshot_name = "TEST"
}

build {
  name = "TEST"
  sources = [
    "source.hcloud.TEST"
  ]
  provisioner "file" {
    source = "some.service"
    destination = "/tmp/some.service"
  }
  provisioner "shell" {
    script = "build.sh"
  }
}

Operating system and Environment details

Gentoo/Linux, Linux 5.18.12, x86-64

Log Fragments and crash.log files

[...] packer-builder-hcloud plugin: [INFO] Attempting SSH connection to [...]:22...
[...] packer-builder-hcloud plugin: [DEBUG] reconnecting to TCP connection for SSH
[...] packer-builder-hcloud plugin: [DEBUG] handshaking with SSH
[...] packer-builder-hcloud plugin: [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
[...] packer-builder-hcloud plugin: [DEBUG] Detected authentication error. Increasing handshake attempts.

==> minecraft.hcloud.TEST: Error waiting for SSH: Packer experienced an authentication error when trying to connect via SSH. This can happen if your username/password are wrong. You may want to double-check your credentials as part of your debugging process. original error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

The feature is fairly simple, if skip_create_image=true we don`t publish AMI in cloud, just run defined provisioners to ensure that all scripts are correct. Otherwise, is skip_create_image=false whole process left unchanged.
I can create pull request for that, just wanna make sure you are cool with it.

Use Case(s)

For example, I have CI/CD pipeline where I build packer image. So I add changes to build configuration in some branch, let`s say feature/change-packer. Now I want to check my scripts are correct before I merge into main branch. In order to do that, whole building process should run but without publishing actual AMI image, it would be done in the main branch.

Potential configuration

skip_create_image=false

Potential References

Such feature already implemented in Google Packer Plugin, link to pull request provided below.
hashicorp/packer#10496

Description

Hello, I don't see a way to attach an Hetzner firewall to the packer instance.

Use Case(s)

I'm building a packer instance on Hetzner that has NFS, this has rcp portmapper opened to the world and I'm receiving alerts from the cloud provider. I should be able to attach an Hetzner firewall to the packer instance like it is already done for all the other VMs I have

Potential configuration

something like firewall_id = number in source "hcloud" ?

Potential References

Thank you

I build a lot snapshots with packer-plugin-hcloud for quick iterations and lately I'm experiencing the following error.

Build 'hcloud' errored after 13 minutes 2 seconds: Could not create snapshot: Creating image failed because of an unknown error. (unknown_error)

The only solution we have for now is to trigger the build again. This issue requests having a clear message on why the snapshot was not created. Was it timed out or something else happened?

Happy to provider more inputs here if required.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

It should be possible to disable ipv4 and/or ipv6 during generation.

Use Case(s)

The image I want to build takes into account which network interfaces are available during generation and configures itself accordingly. It must therefore be possible to deactivate these so that only the active ones can be used later during operation.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

Allow the possibility to apply a snapshot name as the input of a snapshot build. Currently, we only allow for a "OS image" as the base.

Use Case(s)

This would allow for sequential snapshot build, for example with the following chain: ISO Image Ubuntu → Snapshot server → snapshot server-special

Using the Source Build block, I believe, we could even build this chain as Packer build builds in-order of definition.

Potential configuration

There is no difference between 'input' and 'output' definitions, but maybe “base” (so “base_snapshot”) would be applicable both for images and snapshots.

source "hcloud" "server" {
  snapshot_name        = "server-special"
  server_type          = "cx11"
}

source "hcloud" "server-special" {
  snapshot_name        = "server-special"
  server_type          = "cx11"
}

build {
  sources = [
    "source.server"
  ]

  // ...
}

build {
  sources = [
    "source.server-special",
  ]

  source "hcloud.server-special" {
    base_snapshot         = "server"
  }
}

Potential References

• https://www.packer.io/docs/templates/hcl_templates/blocks/build/source
• hashicorp/packer#9154 (comment)

Overview of the Issue

When performing Packer builds with configuration that makes use of the rescue and/or upgrade_server_type options, the build will occasionally fail with an error like Could not enable rescue mode: cannot perform operation because server is locked (locked, 59f51b507a355430).

However, this does not always happen (right now I'm unable to produce it while it was plaguing me all afternoon, which makes me think it might be related to something something system load during working hours). I feel like the firewall label selector thing might be relevant here, does Hetzner Cloud "lock" an instance when rules are applied, using some kind of worker queue? That'd explain the intermittent nature of the problem I've been seeing. I'm not terribly familiar with the Hetzner Cloud APIs, but if an action fails, shouldn't the Packer Plugin retry-backoff, rather than waiting for a result once and considering errors a terminal state?

Reproduction Steps

Run the provided Packer Buildfile until you encounter an error.

Plugin and Packer version

Packer v1.11.0
Plugin v1.5.2

Simplified Packer Buildfile

# test.pkr.hcl

packer {
  required_plugins {
    hcloud = {
      version = "1.5.2"
      source  = "github.com/hetznercloud/hcloud"
    }
  }
}

source "hcloud" "test" {
  location = "fsn1"
  image  = "debian-12"
  rescue = "linux64"
  server_type = "cpx11"
  upgrade_server_type = "cpx31"
  ssh_username = "root"
  server_labels = {
    "allow-icmp"            = "" # Used to trigger assignment of a firewall rule that allows inbound ICMP
    "allow-ssh"             = "" # Used to trigger assignment of a firewall rule that allows inbound TCP connections to port 22 (SSH)
  }
}

build {
  name = "test"

  sources = ["source.hcloud.test"]

  provisioner "shell" {
    inline = [
      "echo hello",
    ]
  }
}

Operating system and Environment details

cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Log Fragments and crash.log files

I'll include logs when I try reproducing the problem again next week.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

It would be helpful to be able to attach a Hetzner volume to the server that is running the Packer build.

Use Case(s)

When you use Packer, you want to build immutable infrastructure. So you generally have your persisted data somewhere outside of the actual server so that it doesn't get lost when you deploy/build a new image. This is often done, by simply having a separate database server. But there is also the use case where you just store your data that needs to be persisted, into a cloud volume. If you do that, the volume needs to be mounted to the image building server, because you want to handle the mounting of the volume during the build of the image. You also don't want to loose the data that gets persisted at the application startup. Application startup typically happens during the build of the image and a typical task would be database initialization/migration.

Potential configuration

Attaching the volume could for example just be configured when describing the source

source "hcloud" "name" {
  image   = "ubuntu"
  ...
  volumes = [ <volume_id> ]
}

Potential References

The Amazon EBS builder offers this functionality as launch_block_device_mappings

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

Could you publish a new release of the packer builder? Latest release v1.0.5 is over a year old, and since then we have merged many improvements and also have a breaking API change (#83) that needs to be released.

Use Case(s)

• Anyone using Packer on 32bit platforms will break with the api change
• We have customers that would like to use the merged improvements

Potential configuration

Potential References

Previously requested in #83.

The docs currently show the old format of doing things via JSON. As a new user to the terraform/packer I'm completely confused over the fact the settings for this plugin look completely different than what is in the docs for packer.

If I had not known about packer hcl2_upgrade I would have wasted time or rejected the project preliminary.

I expect the docs to be in line with the product at all times, so It would be helpful if this would be made sure of. An alternative would be automatically scanning the docs for json style config and adding a note to each affected page that this still uses the old syntax.

This issue was originally opened by @Rick-McClatchie in hashicorp/packer#7980 and has been migrated to this repository. The original issue description is below.

It would be great if there was a way to build Windows Server images with packer in the Hetzner Cloud.
https://www.packer.io/intro/getting-started/build-image.html#a-windows-example