-
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
refactor: Only set ARGO_TEMPLATE
env for init container.
#13761
Conversation
@jswxstw this is great but can u make this change enabled via an environment variable (ARGO_TEMPLATE_ONLY_ON_INIT)? @juliev0 mentioned one of their workflows in main container uses the variable: #8790 (comment) whereas 99% of users (including me) won't and would benefit from your PR |
Thanks for noticing that @tooptoop4 ! I believe this is one motivation for your making #13742 configurable, right? @jswxstw will it make the code too ugly to do that? I'll admit that my use of $ARGO_TEMPLATE environment variable was a hacky workaround for exceeding the maximum size of an argument, as opposed to a promise that Argo Workflows makes will exist. And admittedly, I was later in a separate situation in which for a different Workflow even this hack didn't work, as the environment variable size made the overall Container size too big as I recall. If needed, I can adjust our Workflow so it doesn't try to do this at all. I guess the only question is whether there's anyone else out there for which this will break. |
@juliev0 Agree, I think we should exercise restraint in adding environment variables, as it could increase complexity and confuse users. |
Signed-off-by: oninowang <[email protected]>
Signed-off-by: oninowang <[email protected]>
Signed-off-by: oninowang <[email protected]>
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 this is no longer a feature (unlike #13742, which added an env var) as it doesn't add anything; could be a fix
or refactor
depending on if we want to auto-backport it
I think we should exercise restraint in adding environment variables, as it could increase complexity and confuse users.
Agree.
I do think
ARGO_TEMPLATE
is an internal environment variable, which is not documented and users should not rely on it.
Also agree. I've said similar things elsewhere too and there is precedent for this.
If we wanted to be extra safe, we could make this a breaking fix!
and leave a note in the upgrading guide.
Hey @shuangkun - do you want to review this since you added the configmap offloading PR which it's based on? |
when i tried to patch this got below error in the wait container:
actually i think i'm just not building locally properly, how do you do it? |
It seems you are using the argoexec image of old version: v3.4.11. Not updated? @tooptoop4 |
@jswxstw what command do u use to build the controller locally? |
@tooptoop4 I used |
@agilgur5 Agree, this PR should be a |
ARGO_TEMPLATE
env for init container.ARGO_TEMPLATE
env for init container.
ah this makes sense, i need to build the exec image too not just the controller! |
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 seems like a breaking change. I remember Intuit or other vendors depend on this. @juliev0 Do you remember?
accepted in #13761 (comment) |
Thanks for keeping that in mind, though, @terrytangyuan! |
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.
Thanks!
Sorry, I just found time now. This PR has been merged and it seems there is no problem. |
Fixes #8790
Motivation
duplicative env var ARGO_TEMPLATE result in etcd size 1MB limit
Modifications
Only set
ARGO_TEMPLATE
env for init container, wait container read it from the template file written by init container.Verification
existing UT or E2E tests have covered it.