Cubestore on K8s panics w/o setting CUBESTORE_PORT

[loremaps]

Describe the bug A clear and concise description of what the bug is.

Cubestore panics if deployed on K8s without explicitly setting CUBESTORE_PORT to 3306. Please note that a service must also be deployed to surface the error (which is weird).

To Reproduce Steps to reproduce the behavior:

1. Start a minikube cluster (or any cluster/playground e.g. katacoda
2. Create a service

apiVersion: v1
kind: Service
metadata:
  name: cubestore
  labels:
    app: cubestore
spec:
  ports:
    - port: 3030
      targetPort: 3030
  selector:
    app: cubestore

3. Deploy the service kubectl apply -f service.yaml
4. Create a deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cubestore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cubestore
  template:
    metadata:
      labels:
        app: cubestore
    spec:
      containers:
        - name: cubestore
          image: cubejs/cubestore:v0.28.8
          ports:
            - containerPort: 3030

5. Deploy kubectl apply -f deployment.yaml
6. If you get the pod's logs you will see the error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', cubestore/src/config/mod.rs:458:55
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a143517d44cac50b20cbd3a0b579addab40dd399/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/a143517d44cac50b20cbd3a0b579addab40dd399/library/core/src/panicking.rs:92:14
   2: core::option::expect_none_failed
             at /rustc/a143517d44cac50b20cbd3a0b579addab40dd399/library/core/src/option.rs:1300:5
   3: cubestore::config::Config::default
   4: cubestored::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

If we add the environmental variable it works 🤯 :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cubestore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cubestore
  template:
    metadata:
      labels:
        app: cubestore
    spec:
      containers:
        - name: cubestore
          image: cubejs/cubestore:v0.28.8
          ports:
            - containerPort: 3030
+         env:
+           - name: CUBESTORE_PORT
+             value: "3306"

Expected behavior A clear and concise description of what you expected to happen.

Since the CUBESTORE_PORT defaults to 3306 I would expect to not have to specify it as an env var.

Screenshots If applicable, add screenshots to help explain your problem.

Version: [e.g. 0.4.5]

Cubestore v0.28.8

Additional context Add any other context about the problem here.

[ilya-biryukov]

Thanks for the report. We improved the error messages, they know mention environment variable names.

I could not reproduce your errors even on v0.28.8, though. If I don't mention CUBESTORE_PORT in the yaml file, the deployment works just fine. If I set it to invalid value, e.g. value: "'3306'" it starts producing the error.

[loremaps]

Hi @ilya-biryukov and thank you for looking into this. Did you create the service before applying the deployment?

without the service.yaml it works fine (which is truly weird).

I was able to reproduce it again for v0.28.13 in this katacoda environment

[ilya-biryukov]

You're right, it does reproduce. I must have messed up the sequence. No-one sets CUBESTORE_PORT, so obviously we shouldn't even try to parse it. That's weird indeed.