-
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
Memoization doesn't work in templates that are steps #10769
Comments
It seems like memoization is only declared on execution templates rather than orchestration templates currently. This and #10426 are requesting that it work for orchestration templates |
@JPZ13: Thanks for looking into this. What needs to be done to implement this? I think it's an important missing feature that would allow us to cache more complicated steps that run on big monorepos. |
Not sure about what technical steps, but I'll bring it up at the next contributors meeting to see if anyone has capacity. Would you be interested in contributing it @moleskin-smile? |
I'd love to, but I lack Go skills. :( Thanks for taking care of this issue. |
Despite argoproj#10769 and argoproj#10426 both having examples of memoization not working with the examples having no output, no-one has picked up on this. To address this improve the documentation for memoization and work-avoidance, linking the two ideas and pointing people who want to skip steps towards work-avoidance unless they are really doing what memoization was designed to do. Issue argoproj#10426 is problematic in that some steps get memoized when perhaps they should't, so this commit shouldn't close it. Fixes argoproj#10769 Signed-off-by: Alan Clucas <[email protected]>
This is not a bug. Memoization should not memoize steps without outputs. Adding outputs to the above example does what is intended.
I have put up a PR to try to address this issue through documentation. |
Thanks! That works indeed. |
Please note: I am not totally in favour of this change, it makes memoization work without outputs and I'm not conviced this is actually healthy, but it's what people seem to expect. See the linked issues in the fixes list below. This change will cause memoization to work for all step and dag tasks even without outputs. Note: They were working semi-erroneously for some dag tasks due to implicit outputs before this change. Fixes argoproj#11280 (raised to cover this desire) Fixes argoproj#10769 (already closed by documentation) Partially addresses argoproj#10426: Dags will memoize now, but retries still won't Signed-off-by: Alan Clucas <[email protected]>
Please note: I am not totally in favour of this change, it makes memoization work without outputs and I'm not conviced this is actually healthy, but it's what people seem to expect. See the linked issues in the fixes list below. This change will cause memoization to work for all step and dag tasks even without outputs. Note: They were working semi-erroneously for some dag tasks due to implicit outputs before this change. Fixes argoproj#11280 (raised to cover this desire) Fixes argoproj#10769 (already closed by documentation) Partially addresses argoproj#10426: Dags will memoize now, but retries still won't Signed-off-by: Alan Clucas <[email protected]>
Pre-requisites
:latest
What happened/what you expected to happen?
memoize
configuration added to asteps
template doesn't have any effect. No ConfigMap is created at all.Memoization status is always like this after multiple submits:
It prevents us from caching larger reusable chunks of work exposed via Workflow Templates. For example, building images is a multiple step effort – we have to build an app, login to container registry, build Dockerfile and push image. Entire thing could be cached as a whole, but it doesn't work.
There are few workarounds we considered. We're not happy with neither of them.
memoize
to all of the steps. It's hard to maintain and it's error-prone and sometimes incorrect. For example we we shouldn't cache "container registry login" step, because token it generates has short time to live, but also we don't need it at all if the image is already built (and it's waste of time and resources to login just for nothing).Image building is just an example. We have more use cases for this.
Is there a way to fix or work around this? Thanks!
Similar issue was reported for dag: #10426
Version
v3.4.5
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: