ERROR: relation "scanner" does not exist in version 4.0.4

[imaskm]

Description of Problem / Feature Request

I am trying to deploy version 4.0.4 on a kubernetes cluster but the clair pod is throwing the error and then goes in "CrashLoopBackOff" state.

Expected Outcome

Pod should be in running state

Actual Outcome

clair pod is in "CrashLoopBackOff" state.
I am using istio as a sidecar which injects a proxy container in the pod
kubectl logs showing the error:

kubectl logs clair-748c59f954-jq24n -c clair 2021/04/06 15:56:04 initialized failed: failed to initialize libindex: failed to register configured scanners: failed to get scanner id for scnr dpkg: ERROR: relation "scanner" does not exist (SQLSTATE 42P01)

Environment

• Clair version/image: 4.0.4
• Clair client name/version:
• Host OS:
• Kernel (e.g. uname -a):
• Kubernetes version (use kubectl version): v1.20.4
• Network/Firewall setup: Istio

[ldelossa]

@imaskm my assumption is your config does not instruct Clair to perform migrations.

Please reference the following configuration options and ensure you instruct Clair to perform migrations on the database you're pointing it to.

https://quay.github.io/clair/reference/config.html#migrations-false-1

Each service section "indexer, matcher, notifier" has this "migrations" field and it should be set to "true" if you want Clair to setup the database tables for you.

[imaskm]

Thanks @ldelossa , That solved this issue.

[imaskm]

@ldelossa , On my existing deployment where we are using 2.1.2 version, after setting up the migration as "true", I am getting this error:
2021/04/06 20:17:10 initialized failed: failed to initialize libindex: failed to perform migrations: migration 1 failed: ERROR: column "hash" referenced in foreign key constraint does not exist (SQLSTATE 42703)

[ldelossa]

@imaskm are you attempting to move from a v2 deployment to a v4 deployment?

These are major version difference and there is no clean upgrade path between the two versions.

Clair V4 deployments should utilize a new database, separate from the V2 deployment. You must backfill any V2 contents into V4.

[imaskm]

@ldelossa Is there any workaround for this? like we can follow incremental upgrading if there is any "good path" for upgrades.

[ldelossa]

@imaskm there is not. There's no fluid upgrade path from v2 to v4. You'll need to submit your previously scanned containers to v4.