No archive logs for failed pod #13237
Comments
|
My configuration is here: argo-workflows:
enabled: true
namespaceOverride: autonomy
fullnameOverride: argo-workflows
executor:
image:
# -- Registry to use for the Workflow Executors
registry: quay.io
controller:
image:
# -- Registry to use for the controller
registry: quay.io
serviceAccount:
# -- Create a service account for the server
create: true
# -- Labels applied to created service account
labels: {}
# -- Annotations applied to created service account
annotations: {}
extraArgs:
- --namespaced
- --managed-namespace
- processing
server:
name: server
servicePort: 2746
authModes:
- server
# this can be removed if execute engine support authenticate with token when talking to argo workflow
image:
registry: quay.io # -- Registry to use for the server when installing in AWS CN
serviceAccount:
# -- Create a service account for the server
create: true
# -- Labels applied to created service account
labels: {}
# -- Annotations applied to created service account
annotations: {}
ingress:
enabled: false # we create ingress on our own in order to utilize our template
extraArgs:
- --namespaced
- --managed-namespace
- processing
useStaticCredentials: false
artifactRepository:
# -- Archive the main container logs as an artifact
archiveLogs: true
s3:
bucket: "xxx"
endpoint: "s3.amazonaws.com"
region: "xxx"
roleARN: "xxx"
encryptionOptions:
enableEncryption: true
argo-workflows-config:
enabled: true
namespaceOverride: xxx
ingress:
host: "<argo workflow host>"
apisix:
enabled: true
apisixPluginConfigName: xxxx
sessionSecret: "xxx"
sessionCookieName: "xxx"
server:
servicePort: xxx |
You didn't provide a Workflow that reproduces this. Please follow the instructions in the issue template.
This looks like a Helm configuration, but you didn't say what Helm chart or what version of that Chart you're using. It looks like
For instance, this looks like something custom?
How did your Workflow fail? Without a repro we cannot determine this. Some failure modes cannot have archive logs or artifacts in general, as the failure kills the It's possible this is partially solved by #12413, which you can enable with Also note that the docs do explicitly recommend against using Archive Logs and strongly recommend using proper logging tools. For example, |
agilgur5
added
the
problem/more information needed
agilgur5
changed the title
|
hi @agilgur5 , |
not actionable, very far from an MVCE
I'm sorry, but there isn't much contributors or maintainers can do to help if you can't provide a reproduction nor an error message or similar. That's why it's asked for in nearly all OSS projects. Keep in mind maintainers are also typically overworked and understaffed or underpaid -- we have limited time, so please use it wisely if you get access to it. I am also personally an unpaid volunteer/hobbyist. Your issue could very well be a misconfiguration or an issue due to other things you run in your cluster. We have no way of knowing what the issue is given the little information you provided. A minimum reproducible example is essential when asking for help. The problem needs to be isolated independent of any other services and in a small example, otherwise how do you know it's a bug in Argo's code and not elsewhere?
That's not a valid version of Again it sounds like you're using something custom, which means we cannot know what your I'm not sure how this is related to Argo CD, and I did not ask about that either. At this point the config & examples are very far from minimal, so I will close the issue until a necessary minimal reproduction can be provided. Without that, this issue is not actionable; there's nothing we can realistically do given the limited information, and cannot even confirm a bug let alone root cause and fix it. I can answer some more of your questions below, but that's really all I can do at this point. further questions
I did provide a link to the PR, #12413, which has all possible information and links out to the original issue etc. You can also see the environment variable and its description in the latest docs.
Again it is hard to tell with the limited amount of information, but that does suggest a likely similar root cause as #12993, as a |
Pre-requisites
:latestimage tag (i.e.quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on:latest. If not, I have explained why, in detail, in my description below.What happened/what did you expect to happen?
Had enabled the archive function for argo workflow, but the failed pod logs cannot be archived. While the completed pod logs can.
Version
3.5.7
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: