Argo: Configurable graceful shutdown period for container and sidecar

Created on 21 Sep 2018  路  6Comments  路  Source: argoproj/argo

Is this a BUG REPORT or FEATURE REQUEST?:

FEATURE REQUERST

What happened:

The sidecar is force killed after 10 seconds after the TERM signal which may be not enough for some containers to clean up.

What you expected to happen:

The kubectl support grace-period parameter when terminate a pod. So I think there may have a gracePeriod parameter for container and sidecar instead of a 10s constant for terminate waiting time.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: sidecar-
spec:
  entrypoint: sidecar-example
  templates:
  - name: sidecar-example
    container:
      image: alpine:latest
      command: [sh, -c]
      args: ["hello, world"]
    gracePeriod: 30
    sidecars:
    - name: influxdb
      image: influxdb:1.2
      gracePeriod: 30
enhancement

Most helpful comment

Any update on this?

All 6 comments

@jessesuen Is this acceptable syntax? The grace-period is really necessary for me to make sure all the data are synced successfully before the container is killed. And I think this may also helpful for many other people.

Is there a need for grace period at both the template and sidecar level? It's a bit unsymmetrical for it to be in the sidecar level, but not at container. Since the main container blocks a step from completing, and is not killed in normal circumstances (unlike sidecar), it doesn't seem necessary to have it at both places... so I would either chose template level or sidecar, but probably not both:

I also think we should follow the terminology of the pod spec and use terminationGracePeriodSeconds as the field name:

    // Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request.
    // Value must be non-negative integer. The value zero indicates delete immediately.
    // If this value is nil, the default grace period will be used instead.
    // The grace period is the duration in seconds after the processes running in the pod are sent
    // a termination signal and the time when the processes are forcibly halted with a kill signal.
    // Set this value longer than the expected cleanup time for your process.
    // Defaults to 30 seconds.
    // +optional
    TerminationGracePeriodSeconds *int64 `json:"terminationGracePeriodSeconds,omitempty" protobuf:"varint,4,opt,name=terminationGracePeriodSeconds"`

What if the workflow is terminated and still need some clean up?

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: sidecar-
spec:
  entrypoint: sidecar-example
  templates:
  - name: sidecar-example
    container:
      image: alpine:latest
      command: [sh, -c]
      args: ["hello, world"]
    sidecars:
    - name: influxdb
      image: influxdb:1.2
      terminationGracePeriodSeconds: 30

Follow the terminology of the pod spec terminationGracePeriodSeconds make sense. This is the updated version.

Any update on this?

any update on this guys? =)

Was this page helpful?
0 / 5 - 0 ratings