Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
lknite opened this issue Oct 13, 2024 · 2 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@lknite
Copy link
Contributor

lknite commented Oct 13, 2024

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.

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.

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

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="8080"
or
export PROXMOX_CALLBACK_URL="http://10.4.0.71:8080"
export PROXMOX_CALLBACK_PORT="8080"
or is there a toplevel this would apply to?
export IMAGEBUILDER_CALLBACK_URL="http://10.4.0.71:8080"
export IMAGEBUILDER_CALLBACK_PORT="8080"

Describe alternatives you've considered

I wouldn't be surprised if this ability already existed. I've only been trying to use image-builder for a couple weeks or so now. Mainly I've been searching through issues and documentation. I'll search more this weekend.

Additional context

Would be surprised if this feature didn't already exist. I'm guessing I just haven't found where to set it yet. If it doesn't exist then by adding this feature it would allow more folks to setup pipelines which run via kubernetes, and perhaps lead to better testing and use of image-builder by more folks.


/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 13, 2024
@lknite
Copy link
Contributor Author

lknite commented Oct 14, 2024

Use case suggesting this would be a good feature to implement:

This error seems to be reappearing with my use case of building images for proxmox. The immediate solution so that we are all using the same thing (the same version of SSH) would be to deploy via a container rather than installing all the parts on a local linux system.

@lknite
Copy link
Contributor Author

lknite commented Oct 15, 2024

Moving to SDK where I think the server implementation actually lives:
hashicorp/packer-plugin-sdk#264

@lknite lknite closed this as completed Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants