+1 to shorter flags without unnecessary words

On Mon, Apr 19, 2021, 3:19 PM Robert Bradshaw <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>>
>>>
>>>
>>>
>>>

Reply via email to