The initializer pod spec does not have envFrom
ghostx31 opened this issue · comments
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
- Create a ConfigMap with
RATE
andDURATION
variables and a Kubernetes secret with values. - Apply them.
- 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.
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 👍
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!
@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.
Sure, it seems like a single one liner fix. I'll send a PR once I'm back from work then.