Hi, @GRomR1.

Thank you for pointing out this problem. Yes, it is a known problem, and it seems to us to be the lesser of the evils.

If your hooks, for example with migration, need variables from secrets or configmaps, you can get a whole range of problems:

• the first time you deploying with a hook, it uses secrets/configmaps that haven't been deployed yet
• when you update your secrets/configmaps, the hooks will use the old data
• when you add annotations to secrets/configmaps already created, for example, when you start using a hook, you get errors saying that the objects have already been created

That's why we use this approach.

Maybe it worth to use alternative approach: dont mark configmap/secrets as hook by default, but add optional flag to generate second, "hooked" version of object? Migration jobs will able to use "hooked" configmap/secrets AND chart uninstalling will remove non-hooked ones.

Hi, @evgkrsk.

Thanks for the idea. We've been discussing this too, and it seems there are no better options at the moment.

Agree with @evgkrsk.
This would be an option to user. The variant where exists "hooked" configmap/secrets sounds good! It should be removed after migration job finished.

To me the best option is don't setup this hook annotations because the hook job is an option. Someone like us prefer to run migrations in CI and don't use migration job. And this annotations was clutter up our cluster in review-stands.

Okay, let's try this approach.

@randreev1321 push an additional commit 7860171 that will merge hookAnnotations with genericAnnotations

approve plz

Any updates?