-
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
feat: Template executor plugins. Fixes #5201 #7256
Conversation
I have added many reviewers. This is a fundamental change to how we do templates and I want it to get thorough scrutiny. |
Also added some small comments in https://docs.google.com/document/d/1ul_5iGPGOSo7hkRMyh5YGh2X-WcA5ms3REjmK-TSsqY/edit#. Thought it might be helpful to add the link here for others to chime in as well. |
Kind: cm.Labels[common.LabelKeyConfigMapType], | ||
}, | ||
ObjectMeta: metav1.ObjectMeta{ | ||
Name: strings.TrimSuffix(cm.Name, "-executor-plugin"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to apply any validation to the name?
examples/plugins/executor/hello/hello-executor-plugin-configmap.yaml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick first-pass. This is incredibly exciting!
@alexec I see some features will be deferred to a v2. Is there anything that should be done in this PR to support versioning? A couple things that come to mind:
I also just realized that minimum-version notes should be added once we know what release this will be in. |
Ready for review again. |
This would be
I don't expect we'd change the spec. But maybe refine it. |
lol of course, I should read files. 😆 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a very small number of grammar-type comments.
@crenshaw-dev you got me thinking. I'm not sure we should |
@alexec faaaaiirr.... I guess it depends on how much we think the specs might diverge. I guess we could take the strategy of nesting them. e.g. kind: ArgoWorkflowPlugin # or whatever
spec:
executor: {}
controller: {} Or something like that. I don't have a strong feeling, besides I do believe that different plugin types should be independently enabled for better security. |
Some more thoughts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Second pass
templates: | ||
- name: main | ||
plugin: | ||
hello: { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be more powerful to show a plugin with a non-empty schema as an example. Maybe argosay
instead of hello-world
where you return the input?
@simster7 @crenshaw-dev good enough? |
Update: Nevermind me. I gave it another try and realized that the ouput parameter name provided by the plugin mismatched the parameter name in the workflow. Once it got fixed, I was able to pass the data between plugin invocations. I'm a bit curious if it is possible to access the output parameters provided by a plugin? Consider a scenario where I'd like to pass some data between invocations of a plugin. In my case I'd like to, using a plugin, create a Slack message at the beginning of a workflow and be able to update the message from subsequent steps (in order to avoid clutter in the Slack channel). I could probably store the Slack message ID in the memory of my plugin instance, but I thought I'd be neat to keep the plugin stateless and be able to control which message(s) one wants to update. See the example workflow below. Workflow apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: notifications-test-
spec:
entrypoint: main
templates:
- name: main
steps:
- - name: pre-notification
template: notification
arguments:
parameters:
- name: message
value: "{{workflow.name}} started"
# ...
- - name: post-notification
template: notification
arguments:
parameters:
- name: thread-id
value: "{{workflow.outputs.parameters.slack-thread-id}}"
- name: message
value: "{{workflow.name}} succeeded"
- name: notification
inputs:
parameters:
- name: thread-id
value: ""
- name: message
plugin:
slack:
message: "{{inputs.parameters.message}}"
thread_id: "{{inputs.parameters.thread-id}}"
outputs:
parameters:
# A placeholder output parameter to keep the workflow validation happy
- name: thread-id
globalName: slack-thread-id
value: "" @crenshaw-dev gave me an idea that I could populate the output parameters through the response from my plugin, so I tried the following: Plugin response: {
"node": {
"phase": "Succeeded",
"message": "Slack message sent",
"outputs": {
"parameters": [
{
"name": "thread-id",
"globalName": "slack-thread-id",
"value": "7331"
}
]
}
}
} The result I'm seeing is however that
I've tried Reading through the changeset I see that this is not something that seems to be officially supported (i.e. don't see any tests for it), so I wonder if this is a use-case that you might want to support in the future? |
@kjagiello you should be able to use output parameters. I wonder if your JSON should be this: {
"node": {
"phase": "Succeeded",
"message": "Slack message sent",
"outputs": {
"parameters": [
{
"name": "slack-thread-id",
"value": "7331"
}
]
}
}
} |
Signed-off-by: Alex Collins <alex_collins@intuit.com>
Signed-off-by: Alex Collins <alex_collins@intuit.com>
Signed-off-by: Alex Collins <alex_collins@intuit.com>
Signed-off-by: Alex Collins <alex_collins@intuit.com>
plugin "github.com/argoproj/argo-workflows/v3/workflow/util/plugins" | ||
) | ||
|
||
func NewBuildCommand() *cobra.Command { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this command work for all languages like java, go, etc?
Yes. Thought for complied languages, you'll need to build the image with your complied source code. |
@alexec If have multiple plugins and all are used in the same workflow, how the Agent pod resource will be configured
|
No. It be retried. This is a common case.
No validation. I'm not sure the pod will schedule. I will test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most code review was done by others. We need to detailed doc or video to understand plug-in development. you can add it later. Please test all corner cases.
Signed-off-by: Alex Collins alex_collins@intuit.com
Fixes #5201
Don't bother creating a PR until you've done this:
make pre-commit -B
to fix codegen, lint, and commit message problems.Create your PR as a draft.
does not need to pass.
Tips: