Kubernetes install instructions are broken

[ategen3rt]

My actions before raising this issue

• Read/searched the docs
• Searched past issues

Following the instructions for the helm deploy fail.

1. The container names have changed, so the instructions for creating a super yser are out of date: https://opencv.github.io/cvat/docs/administration/advanced/k8s_deployment_with_helm/#how-to-create-superuser
2. I don't know if it's related, but on a clean install, the vector container fails.

Steps to Reproduce (for bugs)

1. git clone
2. helm dependency update ./helm-chart
3. helm upgrade cvat -i ./helm-chart -f ./helm-chart/values.yaml
4. run command to set admin password

Expected Behaviour

1. Connect to the pod and set the admin password
2. The system starts

Current Behaviour

1. Cannot connect to the pod because the container doesn't exist
2. The initializer job finishes with complete and I can't connect, if I change the container

Context

I cannot start the container in GCP

Your Environment

• Git hash commit: ee1d421
• Other diagnostic information / logs:

2023-09-25T22:01:26.170971Z INFO vector::app: Internal log rate limit configured. internal_log_rate_secs=10
2023-09-25T22:01:26.175205Z INFO vector::app: Log level is enabled. level="vector=info,codec=info,vrl=info,file_source=info,tower_limit=trace,rdkafka=info,buffers=info,lapin=info,kube=info"
2023-09-25T22:01:26.182483Z INFO vector::app: Loading configs. paths=["/etc/vector"]
2023-09-25T22:01:26.204872Z ERROR vector::cli: Configuration error. error=No sources defined in the config.
2023-09-25T22:01:26.204918Z ERROR vector::cli: Configuration error. error=No sinks defined in the config.

[natohutch]

I've had the same issues with a clean install. I'm also unable to login to the fronted or create a user. Changing the vector config, doesn't affect the problem.

[gouzmi]

Exactly same error for me, did you find a workaround ?

[natohutch]

It's pretty hacky, but I did manage to get the tool somewhat working by editing the nginx config on the frontend pod. Just proxypassed the /api route to the backend service. Was planning on looking at this again later and comparing with the docker deployment to see what's going wrong.

[azhavoro]

Fixed in #7631