USER PROBLEM

Say the user installs the secured-cluster-services Helm chart without explicitly enabling Scanner V2 (on secured clusters Scanner V2 is not enabled by default when using the Helm chart). Now, if the user later decides to activate Scanner V2 by setting scannerV2.disable=false, this has the effect that workloads for Scanner V2 are created, but they fail to initialize, because db-password secret for Scanner V2's DB is not created.

FIX

For Scanner V4 we handle this situation and the logic for post-install creation of this secret could probably be copied over to V2. 

Question is, if this is worth the hassle, given that Scanner V2 is scheduled for deprecation.

How to reproduce:

$ helm -n stackrox-sensor install stackrox-secured-cluster-services ./stackrox-secured-cluster-services-chart --set allowNonstandardNamespace=true --set clusterName=sc1 --set centralEndpoint=central.stackrox.svc:443 --set-file crs.file=sc1.yaml

# All components healthy.

$ helm -n stackrox-sensor upgrade stackrox-secured-cluster-services ./stackrox-secured-cluster-services-chart --set allowNonstandardNamespace=true --set clusterName=sc1 --set centralEndpoint=central.stackrox.svc:443 --set-file crs.file=sc1.yaml --set scanner.disable=false
# Scanner doesn't come up properly due to:
#   Warning  FailedMount  95s (x11 over 7m46s)  kubelet            MountVolume.SetUp failed for volume "scanner-db-password" : secret "scanner-db-password" not found