Updates for Big Bang example to PR #237 #267
Conversation
| @@ -24,4 +24,4 @@ RestartSec=5s | |||
| ExecStartPre=/bin/sh -xc '! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service' | |||
| ExecStartPre=-/sbin/modprobe br_netfilter | |||
| ExecStartPre=-/sbin/modprobe overlay | |||
| ExecStart=/usr/local/bin/k3s server --write-kubeconfig-mode=700 | |||
| ExecStart=/usr/local/bin/k3s server --write-kubeconfig-mode=700 --disable traefik | |||
There was a problem hiding this comment.
@jeff-mccoy @YrrepNoj looking for feedback on this.
Reasons why I want to do it:
- Consistent messaging. We are not expecting Ingresses to be available which is why we have the
zarf connectcommand. The user should be expected to deploy their own ingress controller if they want one. We can do some documentation or a Zarf package to make that easy. - Big Bang compatibility. If we do this we can deploy Big Bang to the K3s cluster that Zarf creates and not have to deal with 2 ingress controllers (regardless of whether they initially conflict with eachother or not)
I have not tested changing Istio back to 443 to see if it conflicts with Traefik. I suspect it will, but given my points above, it doesn't matter if it does or not, since having 2 different ingress controllers is not something that is desirable in most cases.
There was a problem hiding this comment.
That's fine with me for now, but I think we need more user discover around appliance mode to understand the need (or not) for an ingress vs just zarf connect. My guess is we will need to keep the ingress as an option but need to better leverage ingressclassname down the road and settle on a pattern. So sure remove it now, but at some point in the future we may need it (or another ingress) for appliance examples. That might be a great way to leverage #250.
RothAndrew
deleted the
feature/multi-distro-support-update-big-bang-example
branch
No description provided.