fix: in-cluster Host, job-execution warning, assistant image tag - #3
Merged
Conversation
Clients inside the cluster reach the API through the forail-web Service, so their Host header is the Service name, not the ingress host. The hardened allowedHosts list did not cover it, so Django answered 400 and the documented forail-operator install (--set forail.url=http://forail-web.<ns>.svc.cluster.local:8013) could not resolve a single object. Append the four Service DNS forms to whatever allowedHosts is set to. They are cluster-internal and derived from the release, so this keeps the list tight — an unknown Host is still rejected with 400 — while making in-cluster access work without every caller having to override its Host header. Verified in the dev cluster: in-cluster calls return 200 with no hostHeader override, a bogus Host still gets 400 at the Django layer, forail-web stays at 0 restarts, and the full Cypress suite passes 101/101.
task.privileged=false is the right default to publish -- a privileged pod with
a host cgroup mount is a trivial container escape to node-root. But Forail runs
project updates and automation jobs through podman inside the task pod, and
podman cannot mount its overlay storage without those privileges, so with the
shipped defaults every job dies moments after launch with
[graphdriver] prior storage driver overlay failed:
mount /var/lib/containers/storage/overlay: permission denied
Nothing surfaces that. The UI shows a project or job sitting in "Pending", the
pods are all healthy, and the reason is buried in the task container's log. The
install looks successful and simply cannot do the one thing it exists for.
Add NOTES.txt so helm prints the warning, the exact error to expect and the
two flags that enable execution, right after install -- and stays quiet once
they are set. Verified both ways with helm install --dry-run.
forail-assistant is not part of the 2026.07.0 release. It ships disabled and was not built or tested for it, but values.yaml still pointed at forail-assistant:2026.07.0 -- a tag nobody is going to push. Nothing pulls it while assistant.enabled=false, so the trap only springs on whoever turns the assistant on, and it springs as ImagePullBackOff with no hint that the tag was never published. Point it at 2026.06.0, which exists, and say in the values file that it moves in lockstep with the next assistant release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three chart fixes needed before 2026.07.0: