feat: add postInitContainers for admintools server job

[caphrim007]

What was changed

Added a postInitContainers section to the end of the admintools server-job.yml

Why?

To complete a feature that was proposed in #624

PR seems abandoned and I needed this feature so I implemented it as described by @robholland

Checklist

2. How was this tested:

Via go test from the charts/temporal/tests/ directory
Via helm unittest . from the charts/temporal/ directory

3. Any docs updates needed?

No

[PhillypHenning]

I do just want to clarify, the reason you want to add this is because of the sequential execution order of the initContainers.

The current value of additionalInitContainers adds init containers infront of the generated actions of checking the persistence and visibility layers. Your intention is to provide a means of adding additional init containers after those containers run.

Is my understanding correct @caphrim007 ?

Request:
You've added the postInitContainer support to server-jobs, please add it to the admintools and the server deployment as well.

[caphrim007]

@PhillypHenning yes, that's correct

[caphrim007]

@PhillypHenning regarding the additions asked for, are you asking that the admintools.postInitContainers value be re-used in admintools-deployment.yaml and server-deployment.yaml?

Or are you asking that a new server.postInitContainers be used in server-deployment.yaml?

The original use case put forth by @robholland, and needed by myself, is specifically for the server-job template. In fact, Rob's use case is exactly my use case; being able to run temporal operator search-attribute create but before "the rest" of the system comes online.

admintools-deployment.yaml, presently, has an additionalInitContainers that covers all of that deployments init containers. It would be redundant, really, to add postInitContainers there additionally.

If you want them in server-deployment, then it would stand to reason to have a server.postInitContainers. The server-deployment.yaml does specify an existing set of init containers, so a postInitContainers would be reasonable here. However, re-using admintools.postInitContainers would likely lead to a conflict, or at least confusion, where (to use Rob and my's use case) temporal operator search-attribute create would be run twice.

lemme know your thoughts. thanks

[PhillypHenning]

After reviewing further, I agree that there would be no point in including the additionalInitContainers for the admin tools. server-Aamintools unlike the server-deployment and server-job, which have Temporal included initContainers, does not have any Temporal included initContainers.

I'm still of the opinion that server-deployment should include the postInitContainers field as to ensure consistent patterns.

Thanks for the call-out on this @caphrim007

[caphrim007]

@PhillypHenning I can ensure consistent patterns, my remaining question is whether I can introduce a new postInitContainers field here

https://github.com/temporalio/helm-charts/blob/main/charts/temporal/values.yaml#L91

instead of re-using the field defined here

https://github.com/temporalio/helm-charts/blob/main/charts/temporal/values.yaml#L373C3-L373C27

my interpretation of what you're asking for is to add a new server.postInitContainers, and that that will be used specifically in the server-deployment.yaml file.

this would meet my and rob's requirements. additionally, it would avoid the same init containers (defined in admintools) being applied twice; once in server-job and once in server-deployment.

Can you confirm I understand your request?

[PhillypHenning]

I would expect to see the postInitContainers field in the server block which would apply to the -deployment and the schema block which would apply to the -job.

[caphrim007]

@PhillypHenning ready for review