Alvearie / alvearie-helm

repository for the helm chart source and package for Alvearie projects

https://artifacthub.io/packages/helm/linuxforhealth

Apache License 2.0

3 stars 5 forks source link

Consider automatically rolling the FHIR deployment on each deploy #44

Closed lmsurpre closed 3 years ago

lmsurpre commented 3 years ago

I made an update to the configMap and then did a helm update. Helm updated the configMap but didn't rollout a new deployment.

Apparently, configMaps are "normally" dynamically loaded, but if we mount them with a subPath then it takes a pod restart to get the new values (see https://github.com/kubernetes/kubernetes/issues/50345 )

For more info on automatically rolling the deployment, see: https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments

lmsurpre commented 3 years ago

I tried the checksum approach documented in that tips and tricks page:

checksum/config: {{ include (print $.Template.BasePath "/configMap.yaml") . | sha256sum }}

Unfortunately, because our configMap.yaml just consists of named templates, I still don't think its properly detecting the updates. I think we'll just go for the brute force rollme: {{ randAlphaNum 5 | quote }} approach.

lmsurpre commented 3 years ago

38 includes the "rollme" annotation described above. feels a bit hacky, but I think it will work.

lmsurpre commented 3 years ago

Looks like I included the annotation at the wrong level. I put it on the deployment's metadata/annotation, but it was supposed to go on the deployment's spec/template/metadata/annotation. Will fix soon.

lmsurpre commented 3 years ago

OK, I snuck the fix into https://github.com/Alvearie/alvearie-helm/pull/54

I suspect this is the real reason that checksum approach wasn't working for me, so I went back to that option for now.