Incompatibility between plugin and http templates
#14211
Comments
|
Maybe similar to #12708, did you check the status of agent pod? Please get the status and logs of agent pod if you can(since it will be deleted when workflow is completed). In addition, can you provide the workflow detail including spec and status? According to the controller logs, the actual running workflow is different from the example you provided, workflow defaults configed in |
jswxstw
added
problem/more information needed
I am yet to see an
No it isn't.
Yes but that's not relevant. # This file describes the config settings available in the workflow controller configmap
apiVersion: v1
kind: ConfigMap
metadata:
name: workflow-controller-configmap
data:
executor: |
resources:
requests:
cpu: 200m
memory: 128Mi
mainContainer: |
resources:
requests:
cpu: 20m
memory: 20Mi
metricsConfig: |
enabled: false
secure: false
# Default values that will apply to all Workflows from this controller, unless overridden on the Workflow-level
# See more: docs/default-workflow-specs.md
workflowDefaults: |
spec:
# Time out after 1h
activeDeadlineSeconds: 3600
# Delete (archive) workflows after 1h
ttlStrategy:
secondsAfterCompletion: 3600
volumeClaimGC:
strategy: OnWorkflowCompletion
podGC:
strategy: OnPodSuccess
deleteDelayDuration: 120s
retryStrategy:
retryPolicy: OnError
limit: 3The whole setup is here if you want to recreate: https://github.com/pipekit/talk-demos/pull/35/files#diff-f9974f30e3e6bc5db30cbefbe6af24ba6a897842664374f76a0e1804bd1c1815 |
|
Your argument in #12078 seems to be that plugins should only live in the same namespace as the workflow. The documentation on this is extremely light: https://argo-workflows.readthedocs.io/en/latest/executor_plugins/#discovery with nothing to suggest that the setup I'm using is wrong. |
tico24
removed
the
problem/more information needed
|
You are also running a workflow in a non-argo namespace just like I did before, I believe this issue is partly due to the unreasonable plugin loading mechanism and partly due to RBAC problems.
There is no |
Again, yes, just like the docs say you can.
I agree. Exactly like the docs advise to set it up. They seem to use the |
|
I will re-run all the tests again later with the plugin in the workflow's namespace and will report back. From this conversation though, it's clear there is a mismatch between the docs and at least your expectation of how users should use |
When running a workflow in non-argo namespace, the agent pod will also load all plugins in namespace In your case, you submit a workflow only includes |
|
Confirmed your hunch. If there are only plugins in the workflow's namespace and not the controller's namespace, it works as expected. |
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?
It seems that users cannot have
pluginsin their cluster and expecthttptemplates to work.This is both undocumented and unexpected.
Setup
hello-worldplugin from argoproj-labs into the same namespace as the controller.Testing on 3.6.4
trueand there IS a plugin installed, the plugin is added as a sidecar of the http template pod AND the http template fails with unclear reasoning. << This is unexpected and undocumented.truebut there is no plugin installed in the cluster, http template runs fine.Testing on 3.5.14
Initially, nothing worked and then I saw extra logs in the controller that aren't on 3.6.x:
(
argois the namespace and serviceaccount of the controller, not the running workflow)After addressing this with extra RBAC, my findings were the same as 3.6.4:
trueand there IS a plugin installed, the plugin is added as a sidecar of the http template pod AND the http template fails with unclear reasoning. << This is unexpected and undocumented.truebut there is no plugin installed in the cluster, http template runs fine.Additional information
I also repeated the 3.6.4 tests with that new secrets permission added, but the results did not change.
Summary of issues
I have not tested on
latestVersion(s)
v3.6.4, v3.5.14
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow 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: