Proposal: Container entry-point

[pditommaso]

It could be convenient to provide a way to specify the container entry-point. This is useful for example to override the container entry point in order to guarantee the execution of the task script/command with the expected interpreter.

[geoffjentry]

👍 - We here this as a common request of Cromwell, so not including it will just incur similar requests for TES

[buchanae]

I think the right solution is to fix the container. If someone is overriding an entrypoint, maybe the container shouldn't have one. It's better for TES if it stays conservative and doesn't add too many conveniences. Sometimes, what seems at first to be a simple convenience, ends up adding troublesome complexity.

Are there scenarios where it's not possible to solve this by modifying the container?

Regardless, we should make sure this idea fits all container runtimes, not just Docker.

[pditommaso]

I think the same, however I saw that's not uncommon to find third party containers defining a custom entry-point. In this case you need to rebuild the container only to override it and use that image.

I think this feature could improve the interoperability with existing container images. However I understand also your worries.

[geoffjentry]

I agree w/ both of you. @buchanae you are exactly right but we see what @pditommaso suggests, that intellectual purity tends to not stand the test of users :)

That said this conversation reminds me that I've tried to be pretty consistent on the side of simplicity & purity for TES, so I should remain so here.

[buchanae]

Looks like it's possible to wrap a container in a new Dockerfile and reset the entrypoint: https://stackoverflow.com/questions/40122152/how-to-remove-entrypoint-from-parent-image-on-dockerfile

Does anyone have experience with that approach?

[pditommaso]

That's doable but it ideally the user should not be required to build and upload a new image only to override the container entrypoint.

[buchanae]

Ya, I guess being overly conservative here isn't really worth the tradeoff of adding one string field to the spec that might be really useful. PR in #106

[delagoya]

I am firmly on the 👎 on this feature request, but am willing to have it in the spec IF the driver projects or 2+ implementors want it.

[adamstruck]

I'd prefer not to have it in the spec for the reasons @buchanae pointed out.

[geoffjentry]

I'd also add to disregard what I said 2 years ago. I do still agree that it's a common request, but I like it less and less over time

[pditommaso]

It could have helped interoperability with existing container, but surely it's not so important. I'm neutral on this.