Hi all, *tl;dr*: keep harness in user-facing container image flag names?
I have a few PRs in-progress for "renaming" the workerHarnessContainerImage flag, i.e. adding a new flag and marking the old flag as deprecated. This is being done to better reflect the Portable framework.. I wanted to create a flag with the same usage (i.e. passing in a single image) - see proposal if you are curious [1]. Python: https://github.com/apache/beam/pull/14575 Java: https://github.com/apache/beam/pull/14557 The names we are choosing between right now are: - --sdk_container_image - "Harness" doesn't mean anything to most users and is already a confusing term, but mostly got carried over from legacy image names where as far as I can tell, we added harness to indicate it started the SDK process/was different from (VM) worker images - Portable runner uses "docker_container_image" currently for the --environment_type=DOCKER --environment_config key - --sdk_harness_container_image - "Harness" is baked into a bunch of different places (other flag --sdk_harness_container_image_overrides for providing multiple image overrides, e.g. for xlang, Dataflow API objects refer to workerHarnessContainerImage/sdkHarnessContainerImages) Right now the PRs are using sdk_container_image and we reached a small consensus about this in the proposal doc, but I wanted to see how strongly (within reasonable time frame) people felt we should keep harness for consistency's sake. As mentioned on the Python PR, we can also alias the other flag to not have harness in the name, but the Dataflow API still refers to harness objects. [1] go/beam-sdk-container-image-flag <https://docs.google.com/document/d/1bGKu8w6Az_1QwLRrH-PfRydO4UqzYgNV4op5af_UdKE/edit?usp=sharing> Thanks! -Emily
