Today, atelet doesn't seem to implement the same entry point resolution in the same way k8s does. It sets the process argv directly from ActorTemplate.spec.containers.command, and never reads the image's ENTRYPOINT / CMD fields.
This introduces some friction as in order to run any image, I need to reverse engineer the image (e.g. docker inspect) and add the entire argv into the command field. I think also having a semantic which is different than k8s Pod spec is not a good idea.
We should think about:
- Fix the argv resolution to consider image's CMD and ENTRYPOINT.
- Add an
args []string field to ActorTemplateSpec.Container and plumb it into the argv resolution.
I think this will also allows us to remove the explicit command: ["/ko-app/<binary-name>"] fields we need to set in all our demos (see for example 1)
Today, atelet doesn't seem to implement the same entry point resolution in the same way k8s does. It sets the process argv directly from
ActorTemplate.spec.containers.command, and never reads the image's ENTRYPOINT / CMD fields.This introduces some friction as in order to run any image, I need to reverse engineer the image (e.g. docker inspect) and add the entire argv into the
commandfield. I think also having a semantic which is different than k8s Pod spec is not a good idea.We should think about:
args []stringfield toActorTemplateSpec.Containerand plumb it into the argv resolution.I think this will also allows us to remove the explicit
command: ["/ko-app/<binary-name>"]fields we need to set in all our demos (see for example 1)