-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Accessing step .main-logs
in WorkflowTemplate no longer works after upgrade v3.4.11 to v3.4.12
#12065
Comments
maybe caused by #11781 ? |
cc @shmruin Would you like to take a look? |
Possible workaround may be to use an |
Yes, this is because of #11781. It seems start checking resolveAllVariables makes problem. The original code doesn't check this because when checkValidWorkflowVariablePrefix, the untrimmed But with the change of trimming, as #11871 does, it starts checking the tag and
It looks like So, Does it mean that the case checks of |
Thanks for the in-depth investigation @shmruin!
It seems like the actual execution has been allowing this for some time, so it indeed sounds like |
It looks like 'artifacts' keyword of output is quite special. By watching the log again, it is not in 'scope' but should works as a keyword. Maybe I can just generalize 'workflows.output.artifacts.' prefix case to something like '*.outputs.artifacts'. |
@agilgur5 , is - name: foobar
inputs:
parameters:
- { name: target }
container:
image: docker/whalesay
command: [ "cowsay" ]
args: [ "{{ inputs.parameters.target }}" ]
outputs:
artifacts:
- name: main-log
path: SOME_MAIN_LOG_PATH See addOutputsToScope. If it is the only case, then I think we can make |
oh I actually missed that, good catch! If so, this isn't documented anywhere I could find. That may be how archive logs function? @ndejong are you using archive logs to store your logs as artifacts? |
Thanks for the time and attention on this - @shmruin - unless I'm mis understanding something here, I don't see how this works
By using the @agilgur5 - yes we are picking up other artifacts from both steps in our workflows, our ability to access the Is there some other way to access the Argo Workflow terminal-output (ie |
Is this specifically via the archive logs feature?
The documented way of doing this is accessing through As far as I can currently tell, |
Yes I see, had not occurred this was a possibility here; yes we use a local minio instance to provide temporary artifact storage in-between steps; indeed the defaults section of our Our workflowDefaults:
spec:
activeDeadlineSeconds: 900
archiveLogs: true
securityContext:
runAsGroup: 2888
runAsNonRoot: true
runAsUser: 2888
serviceAccountName: argo-workflow-sa
ttlStrategy:
secondsAfterCompletion: 10800 ... and our s3:
bucket: artifacts
endpoint: minio.argo.svc.cluster.local:9000
accessKeySecret:
name: minio-credentials
key: accesskey
secretKeySecret:
name: minio-credentials
key: secretkey There are some things that don't quite align though -
I should also describe then:-
We discovered this technique of accessing The reason we use this See the updated example below (on v3.4.11) that fails if you uncomment the 2x parameters items below - it seems that the apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: bugreport-20231023a
spec:
entrypoint: entrypoint-handler
templates:
- name: entrypoint-handler
steps:
- - name: step1
template: step1-template
- - name: step2
template: step2-template
arguments:
artifacts: [ { name: artifact_from_step1, from: "{{ steps.step1.outputs.artifacts.main-logs }}" } ]
# parameters: [ { name: parameter_from_step1, value: "{{ steps.step1.outputs.result }}" } ]
- name: step1-template
container:
image: debian:stable-slim
command: ["/bin/bash", "-c"]
args:
- |
echo "Binary output to STDOUT"
head -c256 /dev/urandom
echo "Binary output to STDERR"
>&2 head -c256 /dev/urandom
- name: step2-template
inputs:
artifacts: [ { name: artifact_from_step1, path: "/tmp/artifact_from_step1" } ]
# parameters: [ { name: parameter_from_step1 } ]
container:
image: debian:stable-slim
command: ["/bin/bash", "-c"]
args:
- |
cat "/tmp/artifact_from_step1" To boil all that down into summary:-
|
Thanks for digging in and providing that detail @ndejong! Since you confirmed it wasn't in your codebase but that you did have @shmruin we may need to add This is still relying on undocumented behavior, so I am a little hesitant to include this, but it is currently a regression since that behavior was allowed before (despite being undocumented). |
Is this "just" a matter of documentation or does it run deeper that that? (sorry, I'm not across the Argo code base) As described above, we discovered the documented parameter Would be happy to create documentation if that's all that's required. |
it would be deeper than that. it may have never really been intended to be exposed to users, I'm not sure. it being "undocumented behavior" is less that it lacks documentation and more that it may never have been a documented "feature" to begin with. as in, it may have just been intended as an internal, and not a user-facing feature. you're currently using it as a feature, so there's a decision to be made here -- should we support that because it happened to be possible before? or should we not support that as that's an internal and was never actually part of the spec? meaning that your prior usage was unintended behavior. That's why I tagged Terry as one of the current Leads of Workflows. I lean toward allowing that behavior, but would defer to Terry on a decision there. |
Pre-requisites
:latest
What happened/what you expected to happen?
We have workflow templates that reference as argument artifact inputs the
.main-logs
output artifact from the a previous step. This arrangement has been working well until a recent upgrade from v3.4.11 to v3.4.12 (same also occurs when upgrading to v3.5.x)The HTTP400 error response content looks like this
The supplied sample workflow will work fine in v3.4.11 and prior but fail in v3.4.12 (and v3.5.x)
Version
v3.4.12
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: