add HTTPCallbackAddress, needed when running within a kubernetes cluster

[lknite]

Change description

When running within a kubernetes workflow/pipelines, the http server used by the vm to communicate back completion cannot be reached directly. Instead, with kubernetes you 'expose' a pod via a LoadBalancer ip or ingress. The exposed ip is available but must be passed in somehow in order for it to be used.

This pull request adds a variable PROXMOX_HTTP_CALLBACK_ADDRESS, which if provided, will be used by the proxmox provider to pass the needed ip to the vm.

Two additional pull requests have been submitted to packer related repos to make this work:

• packer-plugin-sdk: add HTTPCallbackAddress, needed when running within a kubernetes cluster hashicorp/packer-plugin-sdk#268
• packer-plugin-proxmox: add HTTPCallbackAddress, needed when running within a kubernetes cluster hashicorp/packer-plugin-proxmox#305

Related issues

• Fixes Ability to specify callback ip or fqdn & port of HTTP server used by image-builder #1618

[k8s-ci-robot]

Hi @lknite. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign mboersma for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mboersma]

/ok-to-test

[AverageMarcus]

@lknite Would you mind updating the docs also to include mention of this env var and when to use it?

[lknite]

@AverageMarcus of course, ... I like to do documentation right, which usually means a lot of time and effort. I'd like to first see the pull requests on the 2 packer repos get some traction / added in before I start down that path.

[lknite]

@AverageMarcus I'll add a line to the sample clusterctl.yaml on this page (https://github.com/ionos-cloud/cluster-api-provider-proxmox/blob/main/docs/Usage.md#quick-start) with a description; and also add a line for VLAN while I'm in there. I'll also add a note to the page with the container syntax example (https://image-builder.sigs.k8s.io/capi/container-image).

Would it be ok if I were to add the configuration line in a separate pull request or does it need to be added to this one for it to be approved?

[AverageMarcus]

It'd be best to have it included in this PR to make sure documentation is in place when a release is made. Unless you have a solid reason for keeping them separate?

---

One thing I've just realised though - this change is reliant on upstream Packer changes being released, correct?

Are those changes only in plugins and not Packer itself? Because we're currently pinned to an old version of Packer and cannot upgrade.

Also, can we mark this as Draft until the upstream changes are available to use?

[lknite]

@AverageMarcus Only plugins, packer-plugin-sdk & packer-plugin-proxmox, if that works. Is the packer-plugin-sdk version pinned as well?

I have a few reasons to want to do the documentation as a pull request later (mainly that i'm not a git master and there's a good chance i'll break this pull request trying to add to it and squash it) but it doesn't matter, I can throw something together sooner than later. We might have some time anyways, I haven't seen any comments on the two packer related pull requests, not sure what the turn-around time is on those projects, or if I need to do something else like attend a meeting or submit something additional to a review board.

[mboersma]

image-builder only pins Packer itself, so I think your upstream plugin changes will be available to image-builder (eventually).

I agree with Marcus; we should include doc changes in this PR if possible.