Pod fails to load due to issue creating the sqlite file

[jadhad]

Hi,

I'm attempting to execute your helm chart on kubernetes cluster v1.22.4. There were a few issues with the Igress template "api-version" and the 'persistentVolumeClaim' declaration inside the deployment template.

I've made the following modifications to the deployment template, according to the official documentations:

{{- if .Values.bot.enabled }}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: freqtrade
spec:
  selector:
    matchLabels:
      app: freqtrade
  template:
    metadata:
      labels:
        app: freqtrade
    spec:
      containers:
      - name: freqtrade
        image: {{ .Values.image.base }}:{{ .Values.image.tag }}
        command:
        - freqtrade
        args:
        - trade
        - --config
        - /freqtrade/config/config.json
        - --strategy
        - {{ .Values.bot.strategy_name }}
        - --db-url
        - sqlite:////sqlite/tradesv3.sqlite
        volumeMounts:
        - mountPath: /freqtrade/config
          name: config
        - mountPath: /freqtrade/user_data/strategies
          name: strategies
        - mountPath: /sqlite
          name: sqlite
        ports:
        - name: api
          containerPort: 8080
      volumes:
      - name: config
        configMap:
          name: freqtrade-config
      - name: strategies
        configMap:
          name: freqtrade-strategies
      - name: sqlite
        persistentVolumeClaim:
          claimName: freqtrade-sqlite
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: freqtrade-sqlite
spec:
  storageClassName: manual
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: {{ .Values.bot.pvc_size }}
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: freqtrade-pv
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: /sqlite
{{- end }}

When I run the helm chart I can see that the PersistentVolume is created:

kubectl get pv freqtrade-pv
NAME           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
freqtrade-pv   1Gi        RWO            Retain           Bound    default/freqtrade-sqlite   manual                  5m10s

And the PersistentVolumeClaim is also created:

 kubectl get pvc freqtrade-sqlite
NAME               STATUS   VOLUME         CAPACITY   ACCESS MODES   STORAGECLASS   AGE
freqtrade-sqlite   Bound    freqtrade-pv   1Gi        RWO            manual         6m24s

but the pod doesn't start to run with the error:

2021-11-23 04:31:48,036 - freqtrade.exchange.exchange - INFO - Instance is running with dry_run enabled
2021-11-23 04:31:48,036 - freqtrade.exchange.exchange - INFO - Using CCXT 1.61.24
2021-11-23 04:31:48,036 - freqtrade.exchange.exchange - INFO - Applying additional ccxt config: {'enableRateLimit': True, 'rateLimit': 3100}
2021-11-23 04:31:48,040 - freqtrade.exchange.exchange - INFO - Applying additional ccxt config: {'enableRateLimit': True, 'rateLimit': 3100}
2021-11-23 04:31:48,044 - freqtrade.exchange.exchange - INFO - Using Exchange "FTX"
2021-11-23 04:31:54,876 - freqtrade.resolvers.exchange_resolver - INFO - Using resolved exchange 'Ftx'...
2021-11-23 04:31:54,888 - freqtrade.commands.trade_commands - ERROR - (sqlite3.OperationalError) unable to open database file
(Background on this error at: https://sqlalche.me/e/14/e3q8)
2021-11-23 04:31:54,888 - freqtrade.commands.trade_commands - ERROR - Fatal exception!

I've checked the worker node where the pod is deployed and it created a '/sqlite' folder with root ownership. When I attempt to create an empty sqlite DB file, using the 'sqlite3 file.db "VACUUM;"' command and placing it in the node's '/sqlite' folder I get an error:

freqtrade.commands.trade_commands - ERROR - (sqlite3.OperationalError) attempt to write a readonly database

I attempted to give ownership to the folder to the local user / ftuser I get the following error:

trade.commands.trade_commands - ERROR - (sqlite3.OperationalError) unable to open database file

What am I doing wrong? Can you please assist?

[patoarvizu]

Hey @jadhad this sounds like an issue outside of the Helm chart itself, but let me see if I can help.

I see you're using a non-default StorageClass because the chart doesn't allow you to specify it, so that's something we can fix later, but can you tell me what plugin or provider that storage class uses? Does it require additional options/annotations to be set on the PersistentVolumeClaim object? I suspect that this might be an issue with the provisioning of the disk that's causing some permissions issues. The chart itself only creates the Kubernetes API objects, but I haven't tested it against Kubernetes 1.22, so it's possible that some modifications could be required.

Have you tried testing the setup locally following the steps under ./test-local/? You can modify the Makefile to tweak the parameters to k3d to pin it to a specific Kubernetes version.

[jadhad]

First of all - Great Job !!!

The idea to run these pods in kubernetes is much easier then editing the docker-compose files all the time.

As for you comments:

1. I changed the PersistentVolumeClaim chart a bit:

`apiVersion: v1 kind: PersistentVolumeClaim metadata: name: freqtrade-sqlite spec: accessModes:

• ReadWriteOnce resources: requests: storage: {{ .Values.bot.pvc_size }}

  apiVersion: v1 kind: PersistentVolume metadata: name: freqtrade-pv spec: capacity: storage: 1Gi accessModes:

• ReadWriteOnce hostPath: path: /home/k8s-user/sqlite`

  but it still didn't help.

2. What version of Kubernetes you used to develop the chart?
3. I will try to use the 'test-local' and update.

Thank you very much!

[patoarvizu]

Did you add the PersistentVolume object yourself (either manually or on the chart)? The chart assumes that the storage class will automatically provision the PV given a PersistentVolumeClaim. If your storage class plugin requires manual steps, then it's likely this is a configuration issue on that side. Maybe the volume at that path (/home/k8s-user/sqlite) is being created with permissions such that it isn't accessible to the Docker daemon in the host?

I believe when I developed this chart I was using something like Kubernetes 1.18 or 1.19 if that helps.