Answers: <p>A helm hook pretty much has to be a Job or Pod. Thus choosing between using a hook or using a Job doesn't make much sense - you are usually best off using a Job which is annotated as a pre-upgrade hook.</p>
  <p>And yes, the timeout probably needs to be increased by the users. Unfortunately it's not possible to define the timeout in the chart itself.</p>
  <p>In some cases it makes sense to have a db upgrade happen after the helm chart has been applied and in that case it can be a &quot;normal&quot; Job. This pattern however requires coordination between the Pods accessing the DB and the upgrade process such as a table in the DB which declares the version(s) of the schema.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-17T12:25:00.727Z
Answers: How long would you say it's okay for a Helm hook to run? Let's say the migration takes 10 hours, or even 3 days. Would you implement that as a synchronous hook or would that scenario cause you to prefer a normal, asynchronous job (that is coordinated with the actual application Pods)?
Answers: Fabian Schmied
Answers: CC BY-SA 4.0
Answers: 2022-01-17T10:19:48.970Z
Answers: 2022-01-17T10:19:48.970Z
Answers: vaizki
Body: <p>I was wondering which would be more <em>appropriate / idiomatic</em> when writing a Helm-Chart:</p>
  <ol>
  <li>Perform long running operations (such as db-migration) as part of the helm install process via <strong>helm hooks</strong> and inform the users that a longer <em>--timeout</em> is needed</li>
  <li>Perform long running operations as a <strong>Kubernetes-Job</strong></li>
  </ol>
  <p>Edit: I'm talking about db-operations that can take many hours to complete</p>
  
Tags: <kubernetes><helm><kubernetes-helm>
Title: Helm: Long Running Jobs vs Long Running Hooks
UserDisplayName: Inspyro
ThreadText: # Helm: Long Running Jobs vs Long Running Hooks
  
  (Asked by: username_0 on 2022-01-17)
  
  I was wondering which would be more *appropriate / idiomatic* when writing a Helm-Chart:
  
  1. Perform long running operations (such as db-migration) as part of the helm install process via **helm hooks** and inform the users that a longer *--timeout* is needed
  2. Perform long running operations as a **Kubernetes-Job**
  
  Edit: I'm talking about db-operations that can take many hours to complete
  
  **Tags:** kubernetes, helm, kubernetes-helm
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-01-17. Score: 0
  
  A helm hook pretty much has to be a Job or Pod. Thus choosing between using a hook or using a Job doesn't make much sense - you are usually best off using a Job which is annotated as a pre-upgrade hook.
  
  And yes, the timeout probably needs to be increased by the users. Unfortunately it's not possible to define the timeout in the chart itself.
  
  In some cases it makes sense to have a db upgrade happen after the helm chart has been applied and in that case it can be a "normal" Job. This pattern however requires coordination between the Pods accessing the DB and the upgrade process such as a table in the DB which declares the version(s) of the schema.
  
  > **Comments:**
  > **username_2**: How long would you say it's okay for a Helm hook to run? Let's say the migration takes 10 hours, or even 3 days. Would you implement that as a synchronous hook or would that scenario cause you to prefer a normal, asynchronous job (that is coordinated with the actual application Pods)?  
  
  ---
  
  