Latest lab helm chart not installing on rancher desktop

[dwolfson]

Of course this may be an issue with my environment but haven't seen this error before so thought I would document. I loaded latest helm charts and tried to install and got:

helm  install -f ./egeriaConnectors.yaml lab egeria/odpi-egeria-lab --set service.type=NodePortl --set jupyter.tokenSecret=jupyter-lab-secret
Error: INSTALLATION FAILED: cannot re-use a name that is still in use

Not sure what name is already in use or how to clear it...

I tried to install base with a simpler command and got a bit more output:

dwolfson@Lazurus egeriaConnectors % helm install base egeria/egeria-base --set service.type=NodePortl
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: ServiceAccount "strimzi-cluster-operator" in namespace "default" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "base": current value is "lab"

[dwolfson]

Ok - the first error is because the name lab was still around - this seems to be a new behavior? I deleted it and reran - I also had to re-adjust the resource settings for rancher - seem to have gotten lost after I did an update.

Still getting a weird error..not sure why

dwolfson@Lazurus egeriaConnectors % kubectl logs lab-odpi-egeria-lab-core-0 Defaulted container "egeria" out of: egeria, init-connector (init) Error from server: Get "https://192.168.3.108:10250/containerLogs/default/lab-odpi-egeria-lab-core-0/egeria": x509: certificate is valid for 127.0.0.1, 192.168.5.15, fec0::5055:55ff:feba:e739, not 192.168.3.108

There were some changes to my network - I'll explore that. My network seems fine as far as I can tell..

[dwolfson]

Suspect that this is related to rancher - was able to get helm chart running on linux box. (except for Jupyter)

[planetf1]

The first error is caused by reusing the name of the 'release' - in your example it was 'lab'. In theory you can have multiple named releases in the namespace - but I can't promise I've tested that recently. I would recommend you do one 'release' (that's the helm name) per namespace. Not using a duplicate name (within the same namespace) has always been an error.

The second error is caused by trying to install a second instance within the cluster (whether same namespace or not) due to the way strimzi creates cluster wide resources. This is covered at https://egeria-project.org/guides/operations/kubernetes/charts/overview/?h=strimzi#strimzi-permissions-and-co-existance .

It is probably worth adding the example error in the docs as an example to help with search?

[planetf1]

The final error you posted - from when you issue kubectl - indicates a problem with connectivity to the api server. That's going to be down to your chosen implementation of k8s and local configuration/networking. It's not anything to do with egeria, it's infra setup.

[dwolfson]

Thanks - I think I straightened out most of my network issues (does perfection exist?) and the base charts install properly as expected. With the labs charts (on my Mac) all pods start as expected except Jupyter - which gives the error: dwolfson@Lazurus egeriaConnectors % kubectl logs lab-odpi-egeria-lab-jupyter-7ccddf9ccb-j7hzs Error from server (BadRequest): container "jupyter" in pod "lab-odpi-egeria-lab-jupyter-7ccddf9ccb-j7hzs" is waiting to start: CreateContainerConfigError

The labs charts start properly on my Linux box..

[planetf1]

Can you do a kubectl describe pod lab-odpi-egeria-lab-jupyter-7ccddf9ccb-j7hzs or similar -- we need to find out what is the reason behind that error.

Most likely, you have configured jupyter to use a secret, but have not defined the secret. K8s is therefore going to tell you in the 'describe' that it's missing the secret it needs to run the pod........ ;-)