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.
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"
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:
/kind feature