I agree, that is a good point. *From: *Lukasz Cwik <[email protected]> *Date: *Fri, May 3, 2019 at 9:37 AM *To: *dev
The concept of a machine type isn't necessarily limited to Dataflow. If it > made sense for a runner, they could use AWS/Azure machine types as well. > > On Fri, May 3, 2019 at 9:32 AM Ahmet Altay <[email protected]> wrote: > >> This idea was discussed in a PR a few months ago, and JIRA was filed as a >> follow up [1]. IMO, it makes sense to use a namespace prefix. The primary >> issue here is that, such a change will very likely be a backward >> incompatible change and would be hard to do before the next major version. >> >> [1] https://issues.apache.org/jira/browse/BEAM-6531 >> >> *From: *Reza Rokni <[email protected]> >> *Date: *Thu, May 2, 2019 at 8:00 PM >> *To: * <[email protected]> >> >> Hi, >>> >>> Was reading this SO question: >>> >>> >>> https://stackoverflow.com/questions/53833171/googlecloudoptions-doesnt-have-all-options-that-pipeline-options-has >>> >>> And noticed that in >>> >>> >>> https://beam.apache.org/releases/pydoc/2.12.0/_modules/apache_beam/options/pipeline_options.html#WorkerOptions >>> >>> The option is called --worker_machine_type. >>> >>> I wonder if runner specific options should have the runner in the >>> prefix? Something like --dataflow_worker_machine_type? >>> >>> Cheers >>> Reza >>> >>> -- >>> >>> This email may be confidential and privileged. If you received this >>> communication by mistake, please don't forward it to anyone else, please >>> erase all copies and attachments, and please let me know that it has gone >>> to the wrong person. >>> >>> The above terms reflect a potential business arrangement, are provided >>> solely as a basis for further discussion, and are not intended to be and do >>> not constitute a legally binding obligation. No legally binding obligations >>> will be created, implied, or inferred until an agreement in final form is >>> executed in writing by all parties involved. >>> >>
