Skip to content
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

reduce pod definition size #13089

Open
7 of 8 tasks
tooptoop4 opened this issue May 24, 2024 · 3 comments
Open
7 of 8 tasks

reduce pod definition size #13089

tooptoop4 opened this issue May 24, 2024 · 3 comments
Labels

Comments

@tooptoop4
Copy link
Contributor

tooptoop4 commented May 24, 2024

Summary

The pod spec for steps run from argo is quite large and can fill etcd. Wanting to trim this down, I imagine there will be 2 parts:

  1. code changes
  2. docs for configuration of init vs main vs wait containers

thoughts/Qs:

  1. is ARGO_TEMPLATE env variable needed on all 3 containers?
  2. are volumeMounts needed on both main and wait containers?
  3. do all 3 containers need environment variables for communicating with s3 ie via artifactRepository? (i'm guessing main container doesn't)
    • seems this is already handled
  4. ARGO_TEMPLATE is huge, is the ARGO_TEMPLATE env variable containing things it doesn't need? perhaps some containers need things within that other containers don't?
    • more analysis still todo
  5. are ARGO_PROGRESS_PATCH_TICK_DURATION/ARGO_PROGRESS_FILE_TICK_DURATION/ARGO_INCLUDE_SCRIPT_OUTPUT/ARGO_PROGRESS_FILE env variables needed?
  6. do the commands on all the containers need --loglevel/--log-format?
  7. i think within ARGO_TEMPLATE it does not need volumeMounts related to configmaps of user code like some.py configmap
  8. i think within ARGO_TEMPLATE it does not need some user provided env variables

Use Cases

ensure etcd does not fill up

@jswxstw
Copy link
Member

jswxstw commented May 27, 2024

  • is ARGO_TEMPLATE env variable needed on all 3 containers?

ARGO_TEMPLATE may be huge, #12325 provides an optimization solution for EnvVarTemplate offload, perhaps it can be made the default logic. However, its lifecycle is aligned with the workflow, not the pod, considering delete it when pod gc?

are ARGO_PROGRESS_PATCH_TICK_DURATION/ARGO_PROGRESS_FILE_TICK_DURATION/ARGO_INCLUDE_SCRIPT_OUTPUT/ARGO_PROGRESS_FILE env variables needed?

ARGO_PROGRESS_PATCH_TICK_DURATION/ARGO_PROGRESS_FILE_TICK_DURATION/ARGO_PROGRESS_FILE are used to implement self reporting progress.
ARGO_INCLUDE_SCRIPT_OUTPUT is used to determine whether stdout needs to be saved.

I think optimizing the reuse of ARGO_TEMPLATE would be sufficient. The other aspects have minimal impact, there's no need to be overly demanding.

@tooptoop4
Copy link
Contributor Author

tooptoop4 commented Jun 2, 2024

@jswxstw do u know what ARGO_TEMPLATE is for? and do all 3 containers need it?

@jswxstw
Copy link
Member

jswxstw commented Jun 3, 2024

All 3 containers need ARGO_TEMPLATE to prepare inputs or save outputs, and in some types of templates like Script/Resourct/ContainerSet, it serves other purposes as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants