Skip to content

Probe fixes. #1520

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

abhishekbhakat
Copy link

Some probes have exec instead of direct command as we found k8s complaining about having a handler type defined out of HTTP, TCP, Exec and gRPC.

Respective schemas have been updated.

We found these specific configurations working in our environment. Additionally also have a customer validation.

@abhishekbhakat abhishekbhakat marked this pull request as draft May 23, 2025 19:00
…e found k8s complaining about having a handler type defined out of HTTP, TCP, Exec and gRPC.
@abhishekbhakat abhishekbhakat force-pushed the helm-chart-v1-15-0-astro-probe-fixes branch from 084c9e7 to d631c1b Compare May 23, 2025 19:29
@abhishekbhakat abhishekbhakat marked this pull request as ready for review May 23, 2025 19:46
@abhishekbhakat
Copy link
Author

CC @danielhoherd

Comment on lines +194 to +207
{{- if .Values.dagProcessor.readinessProbe }}
readinessProbe:
initialDelaySeconds: {{ .Values.dagProcessor.readinessProbe.initialDelaySeconds }}
timeoutSeconds: {{ .Values.dagProcessor.readinessProbe.timeoutSeconds }}
failureThreshold: {{ .Values.dagProcessor.readinessProbe.failureThreshold }}
periodSeconds: {{ .Values.dagProcessor.readinessProbe.periodSeconds }}
exec:
command:
{{- if .Values.dagProcessor.readinessProbe.command }}
{{- toYaml .Values.dagProcessor.readinessProbe.command | nindent 16 }}
{{- else }}
{{- include "dag_processor_readiness_check_command" . | indent 14 }}
{{- end }}
{{- end }}
Copy link
Member

@danielhoherd danielhoherd May 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

@abhishekbhakat abhishekbhakat May 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah! I think in Airflow chart there is a standard being followed. No yaml has default values hardcoded. All defaults comes from values.schema.json. Only exec.command is sometimes mentioned in the template yamls. Let's keep it that for the time being, perhaps?
There would be too many places to change. And would make more work for future oss airflow charts support.

@Shubham-astro
Copy link

Would you mind adding tests as well?? @abhishekbhakat

@abhishekbhakat
Copy link
Author

Would you mind adding tests as well?? @abhishekbhakat

The current tests use chart's values.yaml as base. I didn't make any changes to values.yaml so that user may or may not define them.
So, we have 2 options:

  • Either, we make a separate values file for tests.
  • Or edit the chart base values file in the PR itself (which tests are already using). (this would also enforce probes with default values unless overwritten, when using base values.yaml)

If I go with option 1, I have to fix all other failures in the test. An example error in tests is below (this has nothing to do with my PR):

Error: parse error at (airflow/templates/workers/worker-deployment.yaml:400): undefined variable "$containerSecurityContextKerberosSidecar"

{{- else }}
- sh
- -c
- "test -f /clean-logs && grep -q 'AIRFLOW__LOG_RETENTION_DAYS' /clean-logs"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in our astro runtime we are using ASTRONOMER__AIRFLOW__WORKER_LOG_RETENTION_DAYS as a env vars - above might fail right

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once this PR is merged we have to override this value in astronomer airflow chart to override this change

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it's a different clean logs script?

readonly RETENTION="${AIRFLOW__LOG_RETENTION_DAYS:-15}"

Can we add that ENV in this repo/branch? If we can, then let's just override the script with the one that we use?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rishkarajgi rishkarajgi requested a review from Shubham-astro May 27, 2025 12:47
@pgvishnuram pgvishnuram merged commit 4508051 into astronomer:helm-chart/v1-15-0-astro May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants