Scott KarpandClaude Fable 5.1
354e223384
From a reading of the gate's documents (2026-10-21): - AGENTS.md: Steps 14 and 15 shown Pending while the Port and both sockets have carried live traffic since the gate was built → Done, with what carries them; "next build task" now points at the open items, the phase tables being complete. - README.md: the repository tree omitted azazel_processor, kushya_generator, mesorah, src/tools and scripts → listed, each in a line. - deploy/ARCHITECTURE.md: the judgment path holds no model, said in writing — the examination is Python patterns and Prolog rules, the judges consult that Prolog; kushya_generator (a fine-tuned model in this repo, not deployed, not wired) is an OFFERER whose output is examined, never a component the bedikah, the engine or a judge consults. The kohen is not the offerer. azazel_processor listed. - The map: the repository is public; eleven files named the ingress NLB's literal address and five the kohen's kubeconfig path. Docs now use the domains (git.bikoret.ch, bikoret.ch) or "<NLB-IP>" with the kubectl query that answers it; the kubeconfig is "$KUBECONFIG" / "$HOME/.kube/<your-cluster>.yaml". gitea-public-apply.sh takes NLB from the environment. None of it was a secret; all of it was a map. - OTP pin: checked, not changed — the segfault in the build log was a source-built OTP 26.2.1 on macOS; the image is hexpm's 26.2.1 with ERL_FLAGS +JMsingle. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
39 lines
1.9 KiB
YAML
39 lines
1.9 KiB
YAML
# Gitea behind the shared ingress — TCP passthrough
|
|
#
|
|
# One NLB for the cluster (<NLB-IP>, the ingress-nginx Service)
|
|
# instead of one per Service. Bikoret is an HTTP Ingress
|
|
# (service.yaml). Gitea has no hostname that resolves
|
|
# (gitea.temple-council.ch is configured in Gitea and exists nowhere),
|
|
# and host-based routing needs a name — so Gitea rides the ingress
|
|
# controller's TCP passthrough on two ports of the same NLB:
|
|
#
|
|
# <NLB-IP>:3000 → temple-council/gitea:80 (HTTP — git, web UI)
|
|
# <NLB-IP>:22 → temple-council/gitea:22 (SSH)
|
|
#
|
|
# Three live objects carry this; only the first is a whole manifest:
|
|
#
|
|
# 1. This ConfigMap.
|
|
# 2. The controller reads it — one argument on the Deployment:
|
|
# kubectl -n ingress-nginx patch deploy ingress-nginx-controller --type=json -p \
|
|
# '[{"op":"add","path":"/spec/template/spec/containers/0/args/-",
|
|
# "value":"--tcp-services-configmap=$(POD_NAMESPACE)/tcp-services"}]'
|
|
# 3. The controller's Service exposes the two ports ON THE NODEPORTS THE
|
|
# SECURITY GROUP ALREADY ALLOWS (they were Gitea's own; the CCM never
|
|
# opens a NodePort — tablets 29, 46):
|
|
# kubectl -n ingress-nginx patch svc ingress-nginx-controller --type=json -p \
|
|
# '[{"op":"add","path":"/spec/ports/-","value":{"name":"gitea-http","port":3000,"targetPort":3000,"protocol":"TCP","nodePort":30575}},
|
|
# {"op":"add","path":"/spec/ports/-","value":{"name":"gitea-ssh","port":22,"targetPort":22,"protocol":"TCP","nodePort":31345}}]'
|
|
# and temple-council/gitea is type ClusterIP (it held 30575/31345 as a
|
|
# LoadBalancer until 2026-10-06).
|
|
#
|
|
# When Gitea has a real name: add an HTTP Ingress for it (TLS via
|
|
# cert-manager) and drop the 3000 line here; SSH stays.
|
|
apiVersion: v1
|
|
kind: ConfigMap
|
|
metadata:
|
|
name: tcp-services
|
|
namespace: ingress-nginx
|
|
data:
|
|
"3000": "temple-council/gitea:80"
|
|
"22": "temple-council/gitea:22"
|