Hello,
You’ll need to run microk8s enable storage dns first, but you should install the latest juju snap using sudo snap install juju --classic and use that, not the juju in microk8s.
Hello again,
Sometimes it can take a while until MicroK8s is ready after you run microk8s enable storage. Did you run microk8s status --wait-ready before bootstrapping juju? Maybe try just waiting a bit and then run juju bootstrap microk8s myk8s again after a few minutes.
Hello @pttr are you running microk8s in the 1.21/stable channel? Kubeflow currently doesn’t support any later versions. You can check with snap info microk8s.
Edit: I’m sorry I was just able to reproduce this with our instructions, there might be something broken on our side, we will try and fix this as soon as possible.
@pttr after further investigation we have discovered that this is an issue with the latest juju version. To bypass this for now, during bootstrap you can do the following:
juju bootstrap microk8s --agent-version="2.9.22"
@alfax1962 thanks for the message. I just ran through everything from scratch again and the only thing I needed that was outside the tutorial was to patch a role for the istio-ingressgateway charm using:
kubectl patch role -n kubeflow istio-ingressgateway-operator -p '{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"name":"istio-ingressgateway-operator"},"rules":[{"apiGroups":["*"],"resources":["*"],"verbs":["*"]}]}'
Did you use the --agent-version="2.9.22" as @dominik.f mentioned? Apart from that I’m not sure what else might be going wrong. If you could provide juju status and juju debug-log info for the failing charm there might be something helpful there. I’d also suggest doing a sudo snap remove microk8s --purge and trying again - perhaps something was left in microk8s that interacted with this?
Thank you @ca-scribner very much for your prompt reply. All was solved. The problem was my network: the site didn’t answer in the timing required by kubernetes. After some hours the pod initialized correctly. Many regards
Yeah sorry I thought we had that model name issue covered in this guide, but must have been an old one. Atm there’s a hard-coded assumption in the upstream kubeflow dashboard code that expects kubeflow to deployed in the k8s namespace kubeflow.
edit: I’ve reconnected my client / controller and done the juju deploy spark-k8s
from there I am a bit lost… going to try to just … load a basic pyspark session… there’s not much documentation on the charmhub about this tho
Edit2: hmmm I seem to have notebooks just scheduling but never getting completed… my juju status shows an error on dex-auth/2
hook failed: "ingress-relation-broken"
Im going to just tear down and start from scratch… and then at the end add juju deploy spark-k8s and retry
Edit3: well after stopping and restarted the notebook it completed… I then tried a basic hello world NB with pyspark… I am assuming I need to set some… environment variables and point now to the spark-k8s application/unit in juju?
I’ve been trying to port forward or create tunnel to access this dashboard since I installed kubeflow on my server. with the socks tunnel I get an error about the hostname not having an ip associated with it and I don’t know exactly how to deal with it