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

[lknite]

Summary

This feature request is just asking that instead of assuming the callback ip will be the same as the ip where the server is running, (which used to makes sense in the days before kubernetes), is to instead have a variable for the ip where the server is running and another variable for the ip/fqdn to use when accessing the http server... and to let me as a user set that second variable.

e.g. callback_url="http://1.2.3.4"

Use case

I'm running image builder via a gitlab runner pipeline (which is running in kubernetes) and need to setup configuration for the callback HTTP server. Using the same IP the server is running on won't work.

Is your feature request related to a problem? Please describe.

When a pod runs in kubernetes its using a local clusterip, that's not reachable by the outside world. Instead, it needs to be exposed via a service. The gitlab runner helm chart has the ability to expose the runner via a service. So far I do not see where I can specify the IP in image-builder. Even better, it would be nice to use an ingress and an FQDN as the FQDN would remain consistent (the gitlab runner helm chart has the ability to specify an ingress).

Describe the solution you'd like

With the gitlab runner running in a pod it can use whatever port it wants, such as port 80. There's no need to have a random port anymore. 1. Need to be able to specify the port to use so it isn't random. Now that the port is predictable it can be exposed via a service. I can take care of that and request a loadbalancer ip. 2. need to be able to specify the ip for image-builder to use in its callback. Preferably, instead of a loadbalancer ip, I'd rather use an ingress. I can take care of creating the ingress. 3. need ability to specify an ingress for image-builder to use in its callback.

Potential configuration

If this ability doesn't already exist, it would be good to add it and configure things via environment variables. Maybe something like:

(top level?)
export CALLBACK_URL="http://10.4.0.71:8080"
export CALLBACK_PORT="8080"
or
export PROXMOX_URL="https://10.0.0.21:8006/api2/json"
export PROXMOX_USERNAME="capmox@pve!capi"
export PROXMOX_CALLBACK_URL="https://image-builder.k.home.net"
export PROXMOX_CALLBACK_PORT="443"
or
export PROXMOX_CALLBACK_URL="http://10.4.0.71:8080"
export PROXMOX_CALLBACK_PORT="8080"

---

/kind feature

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[lknite]

/remove-lifecycle stale