The initializer pod spec does not have envFrom

[ghostx31]

Brief summary

Hi,
I am pretty new to k6 and the operator usage. The initializer pod spec does not seem to have the envFrom option and just has env option as can be seen from these lines compared to the runner pod spec which does have it.

The JSON spec for the initializer does seem to expose the envFrom though as can be inspected from running kubectl explain TestRun.spec.initializer.envFrom:

GROUP:      k6.io
KIND:       TestRun
VERSION:    v1alpha1

FIELD: envFrom <[]Object>

DESCRIPTION:
    <empty>
FIELDS:
  configMapRef  <Object>
    <no description>

  prefix        <string>
    <no description>

  secretRef     <Object>
    <no description>

I am curious to know if this has not yet been implemented or if this is a deliberate decision or if I am just missing something.

This issue arises from a recent issue that I faced which I have posted on Grafana k6-operator community forum

k6-operator version or image

3.2.0

K6 YAML

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: api-test
  namespace: podinfo
spec:
  arguments: -o experimental-prometheus-rw
  parallelism: 4
  script:
    configMap:
      name: api-cm-test
      file: api.js
  runner:
    env: 
      - name: K6_PROMETHEUS_RW_SERVER_URL
        value: http://localhost:9090/api/v1/write
      - name: K6_PROMETHEUS_RW_TREND_STATS
        value: p(95),p(99),min,max,avg,count,sum 
    envFrom: 
      - secretRef:
          name: api-secret
      - configMapRef: 
          name: api-data-cm
  initializer:
    env: 
      - name: "K6_INCLUDE_SYSTEM_ENV_VARS" 
        value: "1"
      - name: "RATE"
        value: '1'
      - name: "DURATION"
        value: '20s'
  # This does not work even though its in the spec
  # envFrom:
    #   - configMapRef:
    #       name: api-data-cm
    #   - secretRef:
    #       name: api-secret

Other environment details (if applicable)

GKE v1.27

Steps to reproduce the problem

1. Create a ConfigMap with RATE and DURATION variables and a Kubernetes secret with values.
2. Apply them.
3. Use the following test as an example:

import http from 'k6/http';
import { check, fail } from 'k6';
import { sleep } from 'k6';

const url = 'https://url-to-test';

export let options = {
  scenarios: {
    constant_request_rate: {
      executor: 'constant-arrival-rate',
      rate: `${__ENV.RATE}`,
      timeUnit: '1s', // 1000 iterations per second, i.e. 1000 RPS
      duration: `${__ENV.DURATION}`,
      preAllocatedVUs: 5, // how large the initial pool of VUs would be
      maxVUs: 10, // if the preAllocatedVUs are not enough, we can initialize more
    },
  }
};

export default function() {
  let res = http.get(url, {
    headers: { 
      'Content-Type': 'application/json',
      'account-id': `${__ENV.ACCOUNTID}`,
      'api-key': `${__ENV.APIKEY}`,
      
    },
  });
  
  console.log(res.json()); 
}

Expected behaviour

The tests should run correctly and should pick the values from the ConfigMap.

Actual behaviour

The initializer pod fails with the error that variables are undefined because it cannot pick up any values from the ConfigMap.

[yorugac]

Hi @ghostx31, yes, it seems like a bug. Thanks for opening the issue.

The initializer pod spec does have the envFrom option but it doesn't pass it to the Job. But after this part is fixed, if your envFrom will be the same for runner and for initializer then you can specify it only for runner. Usually there's no need to tinker with initializer pod spec separately from runner's spec.

IIRC, initially envFrom has been added to pass secrets to the test run - and not at all to pass the options like duration. That's the most likely explanation on why this bug exists.

Btw, 3.2.0 is the version of Helm chart - not of the operator. I'll update the form for issues to make this more clear 👍

[ghostx31]

Thanks for your quick response!

Yes, I realised that there is no real need to mess with the initializer spec but I had to because of the issue I was facing.

I am passing secrets using secretKeyRef but also going through the docs of environmental variables, I felt that since our tests and other YAML objects would be synced with ArgoCD, it made sense to pass configuration values through configMapRef so that devs only needed to change values in their ConfigMaps, but I see what you mean.

Let me know in case I can assist you in any way, i'll be happy to help you resolve this.

Btw, 3.2.0 is the version of Helm chart - not of the operator.

Got it, I'll update my issue too!

[yorugac]

@ghostx31, would you like to create a PR? 🙂 This should be a simple "good first issue" fix, actually: just adding EnvFrom to initializer definition as is happening in runner's definition.

[ghostx31]

Sure, it seems like a single one liner fix. I'll send a PR once I'm back from work then.