[vmalert] operator crashes on crd vmalert.spec.datasource.tlsConfig

[hamelg]

This simple crd triggers a SIGSEGV when the field tlsConfig is present, whatever TLSConfig configuration parameters.
I use the version v0.13.1 from the OperatorHub.
It stops crashing when the tlsConfig section is absent.

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlert
...
  datasource:
    tlsConfig:
      insecureSkipVerify: true
    url: 'https://xxxx.yyyy.svc.cluster.local:9091'
...

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1523b4e]

goroutine 783 [running]:
k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0x0, 0x0, 0x0)
	k8s.io/apimachinery@v0.20.2/pkg/util/runtime/runtime.go:55 +0x10c
panic(0x176a760, 0x255daf0)
	runtime/panic.go:969 +0x1b9
github.com/VictoriaMetrics/operator/controllers/factory.vmAlertSpecGen(0xc0017e4ed8, 0xc0002f6b00, 0xc000ec2730, 0x1, 0x1, 0xc000b7f1d0, 0x6, 0xc0017e4100, 0x9aac19)
	github.com/VictoriaMetrics/operator/controllers/factory/vmalert.go:197 +0x7aae
github.com/VictoriaMetrics/operator/controllers/factory.newDeployForVMAlert(0xc000d62800, 0xc0002f6b00, 0xc000ec2730, 0x1, 0x1, 0xc000b7f1d0, 0x0, 0x1, 0x0)
	github.com/VictoriaMetrics/operator/controllers/factory/vmalert.go:140 +0x177
github.com/VictoriaMetrics/operator/controllers/factory.CreateOrUpdateVMAlert(0x1b611a0, 0xc0003df260, 0xc000d62800, 0x1b75ba0, 0xc0007f79e0, 0xc0002f6b00, 0xc000ec2730, 0x1, 0x1, 0x0, ...)
	github.com/VictoriaMetrics/operator/controllers/factory/vmalert.go:95 +0x427
github.com/VictoriaMetrics/operator/controllers.(*VMAlertReconciler).Reconcile(0xc0007f79e0, 0x1b611a0, 0xc0003df260, 0xc00066d249, 0x7, 0xc00066d240, 0x9, 0xc0003df200, 0x0, 0x0, ...)
	github.com/VictoriaMetrics/operator/controllers/vmalert_controller.go:92 +0x528
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0004b8e60, 0x1b610e0, 0xc0008095c0, 0x17c4c80, 0xc000664d00)
	sigs.k8s.io/controller-runtime@v0.8.1/pkg/internal/controller/controller.go:297 +0x317
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0004b8e60, 0x1b610e0, 0xc0008095c0, 0x0)
	sigs.k8s.io/controller-runtime@v0.8.1/pkg/internal/controller/controller.go:252 +0x205
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1.2(0x1b610e0, 0xc0008095c0)
	sigs.k8s.io/controller-runtime@v0.8.1/pkg/internal/controller/controller.go:215 +0x4a
k8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext.func1()
	k8s.io/apimachinery@v0.20.2/pkg/util/wait/wait.go:185 +0x37
k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0xc000db9750)
	k8s.io/apimachinery@v0.20.2/pkg/util/wait/wait.go:155 +0x5f
k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0xc0017e5f50, 0x1b28500, 0xc0007b7230, 0xc000809501, 0xc0000fe000)
	k8s.io/apimachinery@v0.20.2/pkg/util/wait/wait.go:156 +0xad
k8s.io/apimachinery/pkg/util/wait.JitterUntil(0xc000db9750, 0x3b9aca00, 0x0, 0x1, 0xc0000fe000)
	k8s.io/apimachinery@v0.20.2/pkg/util/wait/wait.go:133 +0x98
k8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext(0x1b610e0, 0xc0008095c0, 0xc0009a0610, 0x3b9aca00, 0x0, 0x19f4601)
	k8s.io/apimachinery@v0.20.2/pkg/util/wait/wait.go:185 +0xa6
k8s.io/apimachinery/pkg/util/wait.UntilWithContext(0x1b610e0, 0xc0008095c0, 0xc0009a0610, 0x3b9aca00)
	k8s.io/apimachinery@v0.20.2/pkg/util/wait/wait.go:99 +0x57
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1
	sigs.k8s.io/controller-runtime@v0.8.1/pkg/internal/controller/controller.go:212 +0x45e

[f41gh7]

Hello, thanks for reporting, will be fixed soon, need to cover with tests all tlsConfig sections, seems like its all affected by this bug.

[f41gh7]

Must be fixed at the 0.14.0 release. Feel free to reopen this issue, if it doesnt help.