Creating Pv-Pool (Using --dev Installation) with Default Values Returns an Error

[shirady]

Environment info

• NooBaa Operator Version: Current master (5.15.0)
• Platform: Kubernetes v1.23.12 | minikube v1.30.1 | Rancher Desktop 1.11.0

Actual behavior

1. Creating pv-pool backingstore in Rejected phase.

Expected behavior

1. Creating pv-pool backingstore in Ready phase.

Steps to reproduce

1. Install noobaa with --dev flag: nooba install --dev --noobaa-image <image-of-current-repo> -n <namespace-name>.
2. Create backingstore with type pv-pool (using the creatiom example here): nooba backingstore create pv-pool <pv-name> -n <namespace-name> --num-volumes 3 --pv-size-gb 17.

More information - Screenshots / Logs / Other output

Output of noobaa-CLI:
noobaa backingstore create pv-pool shira-bs-pv -n test2 --num-volumes 3 --pv-size-gb 17

INFO[0000] ✅ Exists: NooBaa "noobaa"
INFO[0000] ✅ Created: BackingStore "shira-bs-pv"
INFO[0000] ✅ Created: Secret "backing-store-pv-pool-shira-bs-pv"
INFO[0000]
INFO[0000] NOTE:
INFO[0000]   - This command has finished applying changes to the cluster.
INFO[0000]   - From now on, it only loops and reads the status, to monitor the operator work.
INFO[0000]   - You may Ctrl-C at any time to stop the loop and watch it manually.
INFO[0000]
INFO[0000] BackingStore Wait Ready:
INFO[0000] ⏳ BackingStore "shira-bs-pv" Phase is "": waiting...
INFO[0000] ⏳ BackingStore "shira-bs-pv" Phase is "": waiting...
ERRO[0003] ❌ BackingStore "shira-bs-pv" Phase is "Rejected": MinRequestCpu NooBaa BackingStore shira-bs-pv is in rejected phase due to small cpu request 100m, min is 500m

Output of noobaa-CLI:
noobaa backingstore create pv-pool --help

Create pv-pool backing store

Options:
    --limit-cpu='100m':
	Limit cpu for an agent pod

    --limit-memory='400Mi':
	Limit memory for an agent pod

    --num-volumes=0:
	Number of volumes in the store

    --pv-size-gb=0:
	PV size of each volume in the store

    --request-cpu='100m':
	Request cpu for an agent pod

    --request-memory='400Mi':
	Request memory for an agent pod

    --storage-class='':
	The storage class to use for PV provisioning

Usage:
  noobaa backingstore create pv-pool <backing-store-name> [flags] [options]

Use "noobaa options" for a list of global command-line options (applies to all commands).

Output of noobaa-CLI (partial):
nb backingstore create pv-pool shira-bs-pv -n test1 --num-volumes 3 --pv-size-gb 17 --request-cpu 500m --limit-cpu 500m --request-memory 500Mi --limit-memory 500Mi

INFO[0081] ✅ BackingStore "shira-bs-pv" Phase is Ready
INFO[0081]
INFO[0081]
INFO[0081] ✅ Exists: BackingStore "shira-bs-pv"
INFO[0081] ✅ BackingStore "shira-bs-pv" Phase is Ready

# BackingStore spec:
pvPool:
  numVolumes: 3
  resources:
    limits:
      cpu: 500m
      memory: 500Mi
    requests:
      cpu: 500m
      memory: 500Mi
      storage: 17Gi
  secret:
    name: backing-store-pv-pool-shira-bs-pv
    namespace: test1
type: pv-pool

[shirady]

I found that:

noobaa-operator/pkg/backingstore/backingstore.go

Line 254 in 5d7b041

minCPUStringByEnv, minMemoryStringByEnv := getMinimalResourcesByEnv()

In this line (and the function inside of it) it tries to find the DEV_ENV in the CLI process which doesn't exist (we use this environment variable in the operator's deployment) - unless we would set it manually (export DEV_ENV=true in the terminal where the CLI runs).