+1 to dropping "harness". Even if it still occurs in code, we can remove it from the user interface and that is a Good Thing.
Kenn On Mon, Apr 19, 2021 at 3:42 PM Robert Burke <rob...@frantil.com> wrote: > +1 to shorter flags without unnecessary words > > On Mon, Apr 19, 2021, 3:19 PM Robert Bradshaw <rober...@google.com> wrote: > >> I commented on the doc, but I'm also in favor of dropping "harness." >> >> On Mon, Apr 19, 2021 at 3:10 PM Tyson Hamilton <tyso...@google.com> >> wrote: >> >>> I'm in favor of dropping "harness" and going with "sdk_container_image". >>> I don't feel like the word "harness" adds value or clarity. >>> >>> On Mon, Apr 19, 2021 at 11:34 AM Emily Ye <emil...@google.com> wrote: >>> >>>> 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 >>>> >>>> >>>> >>>> >>>>
