Configmap in pre-install hook.

[Onlinehead]

I have a problem with using configmap in pre-install hook.
My scenario:
I need to run some SQL commands on database before first launch of my application and want to use pre-install hook for that.
For that, I trying to load my sql files with commands into configmap and mount it as volume to pre-install hook container.
What is the right way to configure helm for load configmap with sql files before running pre-install hook?
I tried to set weight of hook in configmap, but that was not help.
Thanks!

[thomastaylor312]

@Onlinehead Is it something you could do using an init container instead? There isn't a way to have Helm create the config map beforehand. However, there is a proposal open (#2243) that is discussing adding support for it

[bacongobbler]

ping, any update on this one @Onlinehead? Were you able to fix your issue through some workaround?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[thomastaylor312]

There hasn't been discussion on this in a while, so I am closing it. Feel free to reopen if you still have a question

[kierenj]

@thomastaylor312 In the hooks docs, it says a use-case was to create configmaps before anything else. How would that work / what does that mean?

Can hooks be resources other than jobs? Is this suggesting that secrets needed in pre-install hook jobs should just be a higher-priority hook resource? - although it sounds like it would never be cleaned up on delete?

[greenkiwi]

@kierenj I'm having the same issues. I guess that could be the case, but it seems a bit strange.

[ggtools]

I had the same issue for a similar case (perform some database operations before install/upgrade the actual code) and indeed putting the hook annotations in the configMap is working you only have to be sure of two things:

1. add helm.sh/hook-weight annotations to ensure that the configMap will be created before the actual hook.
2. use the before-hook-creation delete policy. Not putting any policy will trigger a resource already exists during the next upgrade and putting other might delete the config map before the main workload are started.

There's also one caveat which the that the configMap is not displayed in helm status

However may be @thomastaylor312 can reopen the issue because I'm not very confortable with this solution:

• I think running some database scripts during pre-install/pre-upgrade is fairly standard
• The configMap will be delete/created during the upgrade process even if nothing has changed it it. How does this impact some running pods that are using the old version of the configMap? (might be pods that won't need to be changed by the upgrade or the old pods still running before the new versions are up and running)
• If this is the recommended method to use config map in pre-install hooks this should be documented

[jshen28]

Is there a way to use the same configmap for different hooks....