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

Wait for the sidecar container finish during Workflow run #4545

Closed
andreyvelich opened this issue Nov 17, 2020 · 6 comments
Closed

Wait for the sidecar container finish during Workflow run #4545

andreyvelich opened this issue Nov 17, 2020 · 6 comments
Labels
area/executor type/support User support issue - likely not a bug

Comments

@andreyvelich
Copy link
Contributor

Summary

Hi Everyone!

Is it possible to define Workflow when wait container waits until all sidecar pod’s containers are finished ?
Maybe specify some flag to the Workflow controller.

As I can see here, wait container kills all Pod's containers that are not main or wait.

I want to use Argo workflow in my custom CRD which injects additional sidecar container to the created pod and runs the script after main pod's container is finished.
So my sidecar container should not be killed after the main container is complete.


Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

@andreyvelich andreyvelich added the type/feature Feature request label Nov 17, 2020
@sarabala1979
Copy link
Member

sarabala1979 commented Nov 17, 2020

I want to use Argo workflow in my custom CRD which injects additional sidecar container to the created pod and runs the script after main pod's container is finished.

@andreyvelich
Just curious, how you do inject sidecar containers on a created pod?

@andreyvelich
Copy link
Contributor Author

andreyvelich commented Nov 17, 2020

I want to use Argo workflow in my custom CRD which injects additional sidecar container to the created pod and runs the script after main pod's container is finished.

@andreyvelich
Just curious, how you do inject sidecar containers on a created pod?

@sarabala1979 I am using MutatingAdmissionWebhook to mutate additional container to the necessary Pods in the namespace that has required label.
Once Pod is created in this namespace, controller checks if mutation is required.
If it is required, controller adds another container to this Pod.

/cc @gaocegege @johnugeorge

@alexec
Copy link
Contributor

alexec commented Apr 16, 2021

Killing sidecars like this is by design. I don't think we can fix it. The emissary executor does not kill sidecars like this, the controller does it when it sees the wait container has exited. Could you try that? You need v3.1

@alexec alexec closed this as completed Apr 16, 2021
@andreyvelich
Copy link
Contributor Author

Thank you for this information @alexec!
To define Emissary runtime executor I just need to define appropriate label, like in this example: https://github.com/argoproj/argo-workflows/blob/master/examples/container-set-template/workspace-workflow.yaml#L7 ?

@terrytangyuan
Copy link
Member

terrytangyuan commented Apr 19, 2021

@andreyvelich Good to see you around here! Normally you don't have to specify the label in the workflow unless your controller is configured to support multiple types of executors and you want to use a specific executor for that particular workflow. You can just configure your executor in the controller's configmap:

# Specifies the container runtime interface to use (default: docker)
# must be one of: docker, kubelet, k8sapi, pns
# It has lower precedence than either `--container-runtime-executor` and `containerRuntimeExecutors`.
containerRuntimeExecutor: docker

@andreyvelich
Copy link
Contributor Author

Thank you for the clarification @terrytangyuan!
I will try this out.

@agilgur5 agilgur5 added type/support User support issue - likely not a bug area/executor and removed type/feature Feature request labels Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/executor type/support User support issue - likely not a bug
Projects
None yet
Development

No branches or pull requests

5 participants