-
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: Add workflow var for originName #10745
Conversation
f148456
to
9f7e93e
Compare
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.
LGTM, requested a minor typo fix change
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.
LGTM!
| `workflow.namespace` | Workflow namespace | | ||
| `workflow.mainEntrypoint` | Workflow's initial entrypoint | |
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.
This is static. What's the use case to have this available?
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.
The original problem was distinguishing which high level workflow has invoked us. This is not a static for a WorkflowTemplate called from a another place.
Given this use in a workflowTemplate:
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: say-main-entrypoint
spec:
entrypoint: echo
templates:
- name: echo
container:
image: alpine
command: [echo]
args: ["{{workflow.mainEntrypoint}}"]
I can distinguish my caller:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: foo-
spec:
entrypoint: foo
templates:
- name: foo
steps:
- - name: step
templateRef:
name: say-main-entrypoint
template: echo
results in a log of foo
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: bar-
spec:
entrypoint: bar
templates:
- name: bar
steps:
- - name: step
templateRef:
name: say-main-entrypoint
template: echo
results in a log of bar
It fulfills at least some of the original need in #6772 in a different way, and in a less naughty fashion than the templateName option. @terrytangyuan - if you're happy that it's actually useful, I'll add some more documentation to this PR as it's obvious I haven't explained what use this is.
LGMT |
docs/variables.md
Outdated
@@ -243,7 +243,9 @@ For `Template`-level metrics: | |||
| Variable | Description| | |||
|----------|------------| | |||
| `workflow.name` | Workflow name | | |||
| `workflow.templateName` | Workflow template name. This works only for template names, it may give wrong answers for non-generated names | |
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.
At the risk of being verbose, I wonder if we should call this workflowTemplateName
? When I see templateName
, I think of the individual step, not the WorkflowTemplate
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.
From this link: "The terms WorkflowTemplate and template have created an unfortunate naming collision and have created some confusion in the past."
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 know what you mean. To fit the two part naming of all the rest of the variables how about workflowTemplate.name?
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.
For my understanding, does this also represent the CronWorkflow name for a Workflow generated by a CronWorkflow?
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.
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.
So, in that case using workflowTemplate
in the name would also be inaccurate. I'm thinking something like origin
, or otherwise dividing this into multiple variables. What do you think?
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.
So workflow.origin
is your proposal? Or workflow.originName
to demonstrate it's the name of something perhaps.
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.
workflow.originName
sounds good to me. If you'd like you can wait a few days to see if anyone chimes in first, for risk of your changing it once and then needing to change it again.
} { | ||
assert.Equal(t, expected, getTemplateNameFromName(input)) | ||
} | ||
} |
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.
So, it looks like if there's a Workflow whose actual name is for example template-name-1234567890
, we will assume that the origin is template-name
, right?
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.
Yes, that's the point of these tests. Show how originName will behave given a specific name being fed to it as the workflow name.
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.
Oh, sorry, let me clarify my question. What I meant was, say there's a Workflow that wasn't created from a WorkflowTemplate or a CronWorkflow, and it just happens to be named in a way in which it has the "-" followed by a certain number of letters or numbers. In that case, the actual origin should be the entire Workflow name, right?
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.
It should, but it won't be. We're reverse engineering the name. The same might happen for a workflow submitted with a generateName:
or even just a name that matches. I'd prefer to fix this with some "buyer beware" stickers in the documentation - if you want to fool this you're welcome to but you won't get what you want. We could get the controller generated workflows to add annotations of their original name so that we can then re-injest that as the correct name, but that is a fair amount of work to avoid users deliberately being silly when they can just read the instructions instead and not fool the regex. And it still won't work in all cases where workflows are being injected by other tooling including kubectl and argo-events.
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.
The result of a Workflow submitted with a generateName
might actually be pretty good - if your generateName
is foobar-
I guess the origin
would be foobar
, right?
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.
The result of a Workflow submitted with a
generateName
might actually be pretty good - if yourgenerateName
isfoobar-
I guess theorigin
would befoobar
, right?
Yes. But it's impossible to distinguish between name: foobar-123467890
and generateName: foobar-
.
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 thinking about the alternative - I guess somebody would need to include their own sprig function to perform the same transformation you did, right? I recognize that would make the Workflow more complex.
They can already do this, and are... see the issue #6772 this is trying to assist with. We don't need to support overriding the regex in this facility as users can and are already implementing that.
The reliable answer is to use the alternative I've provided in this PR, the entrypoint name instead.
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 like the entrypoint functionality. Are you thinking of maybe just including that in this PR then?
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'd prefer to include both.
mainEntrypoint
is the 'right answer', but it requires work and requires that users write all their workflows with a differing entrypoint, which is not initially likely, as probably they all have them called main
or at least haven't given them good, unique names. Adding controls to ensure mainEntrypoint
is unique for all your workflows ever is problematic.
Because of this, the alternative originName
is a quick fix for people who want a nice distinguishing name with minimal effort and has been shown to work in the field effectively. We can then determine whether we should put more effort into that solution when issues arise, but also point at mainEntrypoint
in the docs. Perhaps we can implement workflow automatically generated annotations from common sources if it proved a popular but flawed feature.
Let me do the documentation that's needed from Terry's first comment, and that might help.
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.
Okay, thanks. I'll leave it to @terrytangyuan to decide if we should include a variable that should only be used in certain circumstances and won't work if used in the wrong circumstance, if it provides value to people. (I'm not sure if we've come across that type of thing before)
workflow/controller/operator_test.go
Outdated
woc.operate(ctx) | ||
assert.Equal(t, "whalesay", woc.globalParams[common.GlobalVarWorkflowMainEntrypoint]) | ||
} | ||
|
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.
Is it possible to add a test for the more interesting cases involving WorkflowTemplate and mainEntryPoint?
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.
Yes, I'm pretty sure that's doable, I will do once we've settled on functionality.
We discussed it today at the contributors meeting. My concern is that this is one-off solution and introduces confusion to users when it doesn't work for other cases. Any thoughts? @sarabala1979 |
Issue argoproj#6772 asks for the template name, but we cannot always know what this is (simplest unknowable is kubectl apply of a workflow with a generateName). This is a split from PR argoproj#10745 to just provide the variable mainEndpoint, which is set to the name of the invoked entrypoint, which is controllable, knowable, and could be used in the same way, and seems like a useful thing to have anyway. Signed-off-by: Alan Clucas <[email protected]>
Issue argoproj#6772 asks for the template name, but we cannot always know what this is (simplest unknowable is kubectl apply of a workflow with a generateName). This is a split from PR argoproj#10745 to just provide the variable mainEndpoint, which is set to the name of the invoked entrypoint, which is controllable, knowable, and could be used in the same way, and seems like a useful thing to have anyway. Signed-off-by: Alan Clucas <[email protected]>
Issue argoproj#6772 asks for the template name, but we cannot always know what this is (simplest unknowable is kubectl apply of a workflow with a generateName). This is a split from PR argoproj#10745 to just provide the variable mainEndpoint, which is set to the name of the invoked entrypoint, which is controllable, knowable, and could be used in the same way, and seems like a useful thing to have anyway. Signed-off-by: Alan Clucas <[email protected]>
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions. |
Issue argoproj#6772 asks for the template name, but we cannot always know what this is (simplest unknowable is kubectl apply of a workflow with a generateName:) So provide that by deduction as originName. See the tests added in this commit for what we're aiming for there. Addresses argoproj#6772. Signed-off-by: Alan Clucas <[email protected]>
Signed-off-by: Alan Clucas <[email protected]>
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions. |
This issue has been closed due to inactivity. Feel free to re-open if you still encounter this issue. |
I'm finding more use cases for this, so as a basic proposal I'm planning to add a label to the sources of workflows that we control that can supply this originName. The label will be used where present to provide this variable. |
Any plans to continue this? |
Not as is. I'll write up a proposal as an issue instead for discussion. |
Add a global workflow variables to allow generic template metrics to identify which workflow they originate from.
Issue #6772 asks for the template name, but we cannot always know what this is (simplest unknowable is kubectl apply of a workflow with a generateName). So provide that by deduction as originName. See the tests added in this commit for what we're aiming for there.
I have added both variables and tested them by invoking very simple workflows. The regex used to generate originName from the Name has a test suite, and has been checked from simple workflows also.
Fixes #6772