Description of the change
Conditionally add a timestamp annotation to each deployment template when the option "forceRedeploy" is true. The added/changed annotation guarantee kubernetes to see a difference and redeploy the pod.
forceRedeploy option applies to deployments and statefulsets of the main portal and druid components. it does NOT apply to:
thirdparty subchart components, e.g. rabbitmq, ingress-nginx, mysql (cannot edit chart definition)
jobs, e.g. db-upgrade, rbac-upgrade, tls-manager (jobs are immutable anyway)
Benefits
This is useful for changes that isn't identified by kubeternes as a difference to redeploy pod when running helm upgrade, e.g. updated image on same tag @latest, or a single environment value change in configmap, etc.
Drawbacks
Additional user inputs. Blindly setting forceRedeploy to true for all deployment components will result in max rolling update time.
The first time changing forceRedeploy from true to false will still incur a redeploy (because changing the annotation to empty from some value is still a change). maintaining false in subsequent upgrade will be fine. we'll have to live with this limitation.
Description of the change Conditionally add a timestamp annotation to each deployment template when the option "forceRedeploy" is true. The added/changed annotation guarantee kubernetes to see a difference and redeploy the pod.
forceRedeploy option applies to deployments and statefulsets of the main portal and druid components. it does NOT apply to:
Benefits This is useful for changes that isn't identified by kubeternes as a difference to redeploy pod when running
helm upgrade
, e.g. updated image on same tag @latest, or a single environment value change in configmap, etc.Drawbacks
Applicable issues n/a
Additional information sample values edit
Checklist
Chart.yaml
according to semver.[charts/gateway]
)values-production.yaml
apart fromvalues.yaml
, ensure that you implement the changes in both files