Re: [VOTE] Release 2.47.0, release candidate #1

[Chamikara Jayalath via dev]

I tried to run a Java multi-lang pipeline and it's failing due to the
following error during worker setup.

Error syncing pod, skipping" err="failed to \"StartContainer\" for
\"sdk-1-0\" with ImagePullBackOff: \"Back-off pulling image \\\"
gcr.io/cloud-dataflow/v1beta3/beam_python3.8_sdk:2.47.0\\\"\""
pod="default/df-runinferenceexample-chami-04271607-gwf8-harness-vj8w"
podUID=37d8de0a068391920b98dce559c4886f

Are these containers not available yet to test Dataflow ?

Thanks,
Cham

On Thu, Apr 27, 2023 at 2:17 PM Robert Bradshaw via dev 
wrote:

> The artifacts and signatures all look good, and I validated a couple of
> Python pipelines in a fresh install.
>
> Assuming all the tests (including the Dataflow ones) pass (modulo the two
> mentioned above; seems a fair justification to not block on those) I'm +1
> (binding) on this release.
>
> On Wed, Apr 26, 2023 at 12:39 PM Jack McCluskey via dev <
> dev@beam.apache.org> wrote:
>
>> There's also a good chance that newer test suites haven't been included
>> in mass_comment.py (
>> https://github.com/apache/beam/blob/master/release/src/main/scripts/mass_comment.py)
>> and as a result they were not executed.
>>
>> On Wed, Apr 26, 2023 at 3:29 PM Jack McCluskey 
>> wrote:
>>
>>> The Dataflow CrossLanguageValidatesRunner GoUsingJava Tests have been
>>> broken for quite some time (https://github.com/apache/beam/issues/21645)
>>> and the Kafka issue is tied to a test timeout that John Casey has fixed but
>>> didn't get cherrypicked (just fell through the cracks while waiting on
>>> tests to pass, but conversations with them led to the conclusion that we
>>> would just get it into an RC2 if necessary since it's a matter of how the
>>> tests run not how the code under test functions.)
>>>
>>> The tests still marked "pending" passed but did not get updated on the
>>> GitHub side from when Jenkins was straining under load, I'm guessing those
>>> builds have since been deleted under our new retention policy to
>>> alleviate the OOM Jenkins issues. I will try to re-run those for the sake
>>> of having clear and obvious results.
>>>
>>> On Wed, Apr 26, 2023 at 3:23 PM Valentyn Tymofieiev 
>>> wrote:
>>>
 Thanks, Jack!

 re [12]:

 I am seeing some test errors - have they been investigated?
 Also, did all test suites run? I think I am not seeing output of some
 of the suites, like

 Run Python Dataflow V2 ValidatesRunner



 On Wed, Apr 26, 2023 at 9:14 PM Jack McCluskey via dev <
 dev@beam.apache.org> wrote:

> Hi everyone,
>
> Please review and vote on the release candidate #3 for the version
> 1.2.3, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> Reviewers are encouraged to test their own use cases with the release
> candidate, and vote +1 if no issues are found.
>
> The complete staging area is available for your review, which includes:
> * GitHub Release notes [1],
> * the official Apache source release to be deployed to dist.apache.org
> [2], which is signed with the key with fingerprint DF3CBA4F3F4199F4 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.47.0-RC1" [5],
> * website pull request listing the release [6], the blog post [6], and
> publishing the API reference manual [7].
> * Java artifacts were built with Gradle 7.5.1 and OpenJDK/Oracle JDK
> 8.0.322.
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2] and PyPI[8].
> * Go artifacts and documentation are available at pkg.go.dev [9]
> * Validation sheet with a tab for 2.47.0 release to help with
> validation [10].
> * Docker images published to Docker Hub [11].
> * PR to run tests against release branch [12].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> For guidelines on how to try the release in your projects, check out
> our blog post at /blog/validate-beam-release/.
>
> *Note: Dataflow containers for Java are still being finalized. I will
> follow up once that is completed; however, this should not block 
> validation
> for other SDKs and runners. *
>
> Thanks,
>
> Jack McCluskey
>
> [1] https://github.com/apache/beam/milestone/10
> [2] https://dist.apache.org/repos/dist/dev/beam/2.47.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4]
> https://repository.apache.org/content/repositories/orgapachebeam-1309/
> [5] https://github.com/apache/beam/tree/v2.47.0-RC1
> [6] https://github.com/apache/beam/pull/26439
> [7] https://github.com/apache/beam-site/pull/644
> [8] https://pypi.org/project/apache-beam/2.47.0rc1/
> [9]
> 

Re: [VOTE] Release 2.47.0, release candidate #1

[Robert Bradshaw via dev]

The artifacts and signatures all look good, and I validated a couple of
Python pipelines in a fresh install.

Assuming all the tests (including the Dataflow ones) pass (modulo the two
mentioned above; seems a fair justification to not block on those) I'm +1
(binding) on this release.

On Wed, Apr 26, 2023 at 12:39 PM Jack McCluskey via dev 
wrote:

> There's also a good chance that newer test suites haven't been included in
> mass_comment.py (
> https://github.com/apache/beam/blob/master/release/src/main/scripts/mass_comment.py)
> and as a result they were not executed.
>
> On Wed, Apr 26, 2023 at 3:29 PM Jack McCluskey 
> wrote:
>
>> The Dataflow CrossLanguageValidatesRunner GoUsingJava Tests have been
>> broken for quite some time (https://github.com/apache/beam/issues/21645)
>> and the Kafka issue is tied to a test timeout that John Casey has fixed but
>> didn't get cherrypicked (just fell through the cracks while waiting on
>> tests to pass, but conversations with them led to the conclusion that we
>> would just get it into an RC2 if necessary since it's a matter of how the
>> tests run not how the code under test functions.)
>>
>> The tests still marked "pending" passed but did not get updated on the
>> GitHub side from when Jenkins was straining under load, I'm guessing those
>> builds have since been deleted under our new retention policy to
>> alleviate the OOM Jenkins issues. I will try to re-run those for the sake
>> of having clear and obvious results.
>>
>> On Wed, Apr 26, 2023 at 3:23 PM Valentyn Tymofieiev 
>> wrote:
>>
>>> Thanks, Jack!
>>>
>>> re [12]:
>>>
>>> I am seeing some test errors - have they been investigated?
>>> Also, did all test suites run? I think I am not seeing output of some of
>>> the suites, like
>>>
>>> Run Python Dataflow V2 ValidatesRunner
>>>
>>>
>>>
>>> On Wed, Apr 26, 2023 at 9:14 PM Jack McCluskey via dev <
>>> dev@beam.apache.org> wrote:
>>>
 Hi everyone,

 Please review and vote on the release candidate #3 for the version
 1.2.3, as follows:
 [ ] +1, Approve the release
 [ ] -1, Do not approve the release (please provide specific comments)

 Reviewers are encouraged to test their own use cases with the release
 candidate, and vote +1 if no issues are found.

 The complete staging area is available for your review, which includes:
 * GitHub Release notes [1],
 * the official Apache source release to be deployed to dist.apache.org
 [2], which is signed with the key with fingerprint DF3CBA4F3F4199F4 [3],
 * all artifacts to be deployed to the Maven Central Repository [4],
 * source code tag "v2.47.0-RC1" [5],
 * website pull request listing the release [6], the blog post [6], and
 publishing the API reference manual [7].
 * Java artifacts were built with Gradle 7.5.1 and OpenJDK/Oracle JDK
 8.0.322.
 * Python artifacts are deployed along with the source release to the
 dist.apache.org [2] and PyPI[8].
 * Go artifacts and documentation are available at pkg.go.dev [9]
 * Validation sheet with a tab for 2.47.0 release to help with
 validation [10].
 * Docker images published to Docker Hub [11].
 * PR to run tests against release branch [12].

 The vote will be open for at least 72 hours. It is adopted by majority
 approval, with at least 3 PMC affirmative votes.

 For guidelines on how to try the release in your projects, check out
 our blog post at /blog/validate-beam-release/.

 *Note: Dataflow containers for Java are still being finalized. I will
 follow up once that is completed; however, this should not block validation
 for other SDKs and runners. *

 Thanks,

 Jack McCluskey

 [1] https://github.com/apache/beam/milestone/10
 [2] https://dist.apache.org/repos/dist/dev/beam/2.47.0/
 [3] https://dist.apache.org/repos/dist/release/beam/KEYS
 [4]
 https://repository.apache.org/content/repositories/orgapachebeam-1309/
 [5] https://github.com/apache/beam/tree/v2.47.0-RC1
 [6] https://github.com/apache/beam/pull/26439
 [7] https://github.com/apache/beam-site/pull/644
 [8] https://pypi.org/project/apache-beam/2.47.0rc1/
 [9]
 https://pkg.go.dev/github.com/apache/beam/sdks/v2@v2.47.0-RC1/go/pkg/beam
 [10]
 https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=.
 ..
 [11] https://hub.docker.com/search?q=apache%2Fbeam=image
 [12] https://github.com/apache/beam/pull/26152

>>>
>>>

 --


 Jack McCluskey
 SWE - DataPLS PLAT/ Dataflow ML
 RDU
 jrmcclus...@google.com

Beam Dependency Check Report (2023-04-27)

[Apache Jenkins Server]

<<< text/html; charset=UTF-8: Unrecognized >>>

[TANGENT] Beam 3.0 / DoFn API thoughts

[Kenneth Knowles]

Appropriately changed subject as it is just random thoughts :-)

On Thu, Apr 27, 2023 at 9:37 AM Vincent Marquez 
wrote:

>
>> As an example of both of the above: it can be very hard to fix API
>> designs like DoFn (or JUnit classes, etc) of the start/doSomething/end
>> variety that rely on a caller to invoke methods in a particular order and
>> have significant inter-method stateful dependencies that are not at all
>> guaranteed by their design.
>>
>
> Maybe warrants a new topic, but has there been any talk about what a
> newer, more principled Beam 3.0 user facing API might look like and if
> not,  is it something you've given some thought to?
>

I don't think Beam 3.0 will be any time soon, but the community could prove
me wrong. I think the case for user value is just not there, so we would
have to figure that out. Ideally most of the new things would be available
in Beam 2.x under a --beam-3 flag so users can opt in, and then Beam 3.0 is
just "flip the switch". This may not be realistic. Actually my favorite
versioning model is the old Linux Kernel model where every odd version is
another 0.x round of new changes, and even versions are perfectly stable.
This allows rapid development to occur alongside more conservative
maintenance.

About the DoFn API: yes, there are very simple reliable patterns for things
like this. You don't do things like setup(); startBundle(); process();
finishBundle(); teardown() all on one object. Instead, you have an object
with setup() that returns a closeable thing that has startBundle() that
returns a closeable thing that has process() method. Now naming can get
challenging, since you may not like names like DoFnFactoryFactory (with
setup() method) and DoFnFactory (with startBundle() method) and then DoFn
(with process() method) :-). Fixing DoFn doesn't require anything fancy,
really.

And there is another very real problem with DoFn because the annotation
driven API is (in theory) good for users but bad for automation and
composing. The DoFnInvoker class was meant for internal use only but it is
the right sort of API for automated building of DoFns that wrap other DoFns.

Kenn



>
>
>
>
>
>> Such APIs are extremely fragile and the source of a huge number of bugs
>> because it is very easy and common to invoke methods in an order or
>> multiplicity that was not designed for. Not at all coincidentally, it is
>> quite hard and annoying to add the needed "Requires" and "Ensures"
>> annotations to get them to type check, and also very hard and annoying to
>> satisfy those requirements when calling the methods. This is all a feature
>> - the design was bad, and the difficulty setting up and satisfying the
>> invariants helps you realize it.
>>
>> /lecture :-)
>>
>> Kenn
>>
>> On Tue, Apr 25, 2023 at 9:56 AM Damon Douglas 
>> wrote:
>>
>>> Hello Everyone,
>>>
>>> *For those experienced with Beam*:
>>>
>>> PR/26413 [1] begins the long journey of addressing [2] which is a
>>> subtask of [3].  千里之行，始於足下 :-)
>>>
>>> *For those beginning on the learning path*:
>>>
>>> The pull request referenced in the email is not directly related to Beam
>>> but involves a Java annotation called SuppressWarnings.  Per its namesake,
>>> it suppresses warnings according to the values you set in the annotation.
>>> In [2] and [3]'s context the particular setting is "nullness" that
>>> suppresses any warnings related to potentially null references in the code.
>>>
>>> In the Beam repository, we utilize The Checker Framework [4] to help
>>> maintain a clean codebase.  When such annotation applies, it will
>>> essentially mask these warnings and let the code pass without errors.  When
>>> removing the SuppressWarnings with "nullness" annotation, the checks fail.
>>>
>>> Why is this a big deal?  The danger of nullness and the validity of the
>>> warnings depend on the code context.  However, as of this writing there are
>>> many Java classes in our repository with the SuppressWarnings annotation.
>>> What is the likelihood they are masking something serious?
>>>
>>> Here in our discussion would be a great place to be practical and relay
>>> what can be done when receiving a null-related error from the checker
>>> framework.  However, I want to wait after I do more of these and find
>>> validation through peer review.  Then, I will follow-up with the dev list.
>>>
>>> Meanwhile, you can take a look at my attempt in the PR [1].
>>>
>>> Best,
>>>
>>> Damon
>>>
>>> *References*:
>>> 1. https://github.com/apache/beam/pull/26413
>>> 2. https://github.com/apache/beam/issues/20498
>>> 3. https://github.com/apache/beam/issues/20497
>>> 4. https://checkerframework.org/
>>>
>>>
>>>
> *~Vincent*
>

Re: [20498] Remove SuppressWarnings nullness from SelectByteBuddyHelpers

[Vincent Marquez]

On Tue, Apr 25, 2023 at 12:26 PM Kenneth Knowles  wrote:

> This is great work. Thanks for writing about it.
>
> I hold a stronger opinion than "the danger of nullness and the validity of
> the warnings depend on the code context": nullness is a solved problem, and
> type systems solved it, decades ago in some languages and more recently in
> Java. Nullness errors are a choice, and we should not choose to have them.
> Treat them as you would treat any other type error.
>
> And I hold even strong opinions than that! Almost all the time, unclear
> nullness/typing has an underlying cause of lack of clarity in design and
> thinking. This is why fixing nullness almost always improves the code, but
> also why it can be difficult to do after the fact, because it can require
> fixing a bad or broken design. But sometimes it is easy, and you should do
> it with gusto in either way :-)
>
> And more! If checkerframework cannot determine the correctness of
> something, probably neither can you. You may think you can, but you are
> probably wrong. And even if you are correct today, the next person coming
> along will not have your internal mental state and will easily break it.
>
> As an example of both of the above: it can be very hard to fix API designs
> like DoFn (or JUnit classes, etc) of the start/doSomething/end variety that
> rely on a caller to invoke methods in a particular order and have
> significant inter-method stateful dependencies that are not at all
> guaranteed by their design.
>

Maybe warrants a new topic, but has there been any talk about what a newer,
more principled Beam 3.0 user facing API might look like and if not,  is it
something you've given some thought to?





> Such APIs are extremely fragile and the source of a huge number of bugs
> because it is very easy and common to invoke methods in an order or
> multiplicity that was not designed for. Not at all coincidentally, it is
> quite hard and annoying to add the needed "Requires" and "Ensures"
> annotations to get them to type check, and also very hard and annoying to
> satisfy those requirements when calling the methods. This is all a feature
> - the design was bad, and the difficulty setting up and satisfying the
> invariants helps you realize it.
>
> /lecture :-)
>
> Kenn
>
> On Tue, Apr 25, 2023 at 9:56 AM Damon Douglas 
> wrote:
>
>> Hello Everyone,
>>
>> *For those experienced with Beam*:
>>
>> PR/26413 [1] begins the long journey of addressing [2] which is a subtask
>> of [3].  千里之行，始於足下 :-)
>>
>> *For those beginning on the learning path*:
>>
>> The pull request referenced in the email is not directly related to Beam
>> but involves a Java annotation called SuppressWarnings.  Per its namesake,
>> it suppresses warnings according to the values you set in the annotation.
>> In [2] and [3]'s context the particular setting is "nullness" that
>> suppresses any warnings related to potentially null references in the code.
>>
>> In the Beam repository, we utilize The Checker Framework [4] to help
>> maintain a clean codebase.  When such annotation applies, it will
>> essentially mask these warnings and let the code pass without errors.  When
>> removing the SuppressWarnings with "nullness" annotation, the checks fail.
>>
>> Why is this a big deal?  The danger of nullness and the validity of the
>> warnings depend on the code context.  However, as of this writing there are
>> many Java classes in our repository with the SuppressWarnings annotation.
>> What is the likelihood they are masking something serious?
>>
>> Here in our discussion would be a great place to be practical and relay
>> what can be done when receiving a null-related error from the checker
>> framework.  However, I want to wait after I do more of these and find
>> validation through peer review.  Then, I will follow-up with the dev list.
>>
>> Meanwhile, you can take a look at my attempt in the PR [1].
>>
>> Best,
>>
>> Damon
>>
>> *References*:
>> 1. https://github.com/apache/beam/pull/26413
>> 2. https://github.com/apache/beam/issues/20498
>> 3. https://github.com/apache/beam/issues/20497
>> 4. https://checkerframework.org/
>>
>>
>>
*~Vincent*

Beam Summit’s Keynotes are now confirmed!

[Carolina Escobar]

[image: image.png]


Beam Summit is back with incredible Keynotes that you’ll love!

We have prepared an amazing Program  for
you. Don't miss your chance to attend the Keynotes, track talks, and
exceptional networking activities.


Check out the remarkable keynotes we have for you:


[image: image.png]

A case for resource-conscious autotuning in stream processing systems
In
this talk, Vasia will introduce resource-conscious reconfiguration and show
how knowledge about streaming workloads and their execution can improve
application performance without requiring additional resources

[image: image.png]

Beam ML Past, Present, and Future
An
overview of Beam ML capabilities that have been added since the last Beam
Summit, and where Beam ML is headed next

[image: image.png]

Founders' Panel
Kenn
Knowles and Robert Bradshaw talk and look back at their early experiences
building streaming and batch systems, and where Beam has gone so far.


Registration is open!

Remember that Beam Summit is a free event, save your spot and…

Register Now 


See you in NYC at Beam Summit 2023!


[image: image.png]

Beam High Priority Issue Report (31)

[beamactions]

This is your daily summary of Beam's current high priority issues that may need 
attention.

See https://beam.apache.org/contribute/issue-priorities for the meaning and 
expectations around issue priorities.

Unassigned P1 Issues:

https://github.com/apache/beam/issues/26343 [Bug]: 
apache_beam.io.gcp.bigquery_read_it_test.ReadAllBQTests.test_read_queries is 
flaky
https://github.com/apache/beam/issues/26329 [Bug]: BigQuerySourceBase does not 
propagate a Coder to AvroSource
https://github.com/apache/beam/issues/26126 [Failing Test]: 
beam_PostCommit_XVR_Samza permared validatesCrossLanguageRunnerGoUsingJava 
TestDebeziumIO_BasicRead
https://github.com/apache/beam/issues/26041 [Bug]: Unable to create 
exactly-once Flink pipeline with stream source and file sink
https://github.com/apache/beam/issues/25975 [Bug]: Reducing parallelism in 
FlinkRunner leads to a data loss
https://github.com/apache/beam/issues/24776 [Bug]: Race condition in Python SDK 
Harness ProcessBundleProgress
https://github.com/apache/beam/issues/24389 [Failing Test]: 
HadoopFormatIOElasticTest.classMethod ExceptionInInitializerError 
ContainerFetchException
https://github.com/apache/beam/issues/24313 [Flaky]: 
apache_beam/runners/portability/portable_runner_test.py::PortableRunnerTestWithSubprocesses::test_pardo_state_with_custom_key_coder
https://github.com/apache/beam/issues/23944  beam_PreCommit_Python_Cron 
regularily failing - test_pardo_large_input flaky
https://github.com/apache/beam/issues/23709 [Flake]: Spark batch flakes in 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElement and 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInStartBundle
https://github.com/apache/beam/issues/22913 [Bug]: 
beam_PostCommit_Java_ValidatesRunner_Flink is flakes in 
org.apache.beam.sdk.transforms.GroupByKeyTest$BasicTests.testAfterProcessingTimeContinuationTriggerUsingState
https://github.com/apache/beam/issues/22605 [Bug]: Beam Python failure for 
dataflow_exercise_metrics_pipeline_test.ExerciseMetricsPipelineTest.test_metrics_it
https://github.com/apache/beam/issues/21706 Flaky timeout in github Python unit 
test action 
StatefulDoFnOnDirectRunnerTest.test_dynamic_timer_clear_then_set_timer
https://github.com/apache/beam/issues/21645 
beam_PostCommit_XVR_GoUsingJava_Dataflow fails on some test transforms
https://github.com/apache/beam/issues/21643 FnRunnerTest with non-trivial 
(order 1000 elements) numpy input flakes in non-cython environment
https://github.com/apache/beam/issues/21469 beam_PostCommit_XVR_Flink flaky: 
Connection refused
https://github.com/apache/beam/issues/21424 Java VR (Dataflow, V2, Streaming) 
failing: ParDoTest$TimestampTests/OnWindowExpirationTests
https://github.com/apache/beam/issues/21262 Python AfterAny, AfterAll do not 
follow spec
https://github.com/apache/beam/issues/21260 Python DirectRunner does not emit 
data at GC time
https://github.com/apache/beam/issues/21121 
apache_beam.examples.streaming_wordcount_it_test.StreamingWordCountIT.test_streaming_wordcount_it
 flakey
https://github.com/apache/beam/issues/21104 Flaky: 
apache_beam.runners.portability.fn_api_runner.fn_runner_test.FnApiRunnerTestWithGrpcAndMultiWorkers
https://github.com/apache/beam/issues/20976 
apache_beam.runners.portability.flink_runner_test.FlinkRunnerTestOptimized.test_flink_metrics
 is flaky
https://github.com/apache/beam/issues/20108 Python direct runner doesn't emit 
empty pane when it should
https://github.com/apache/beam/issues/19814 Flink streaming flakes in 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInStartBundleStateful and 
ParDoLifecycleTest.testTeardownCalledAfterExceptionInProcessElementStateful
https://github.com/apache/beam/issues/19465 Explore possibilities to lower 
in-use IP address quota footprint.


P1 Issues with no update in the last week:

https://github.com/apache/beam/issues/26354 [Bug]: BigQueryIO direct read not 
reading all rows when set --setEnableBundling=true
https://github.com/apache/beam/issues/26280 [Task]: Allow users to pass their 
own service name for google cloud profiler 
https://github.com/apache/beam/issues/23525 [Bug]: Default PubsubMessage coder 
will drop message id and orderingKey
https://github.com/apache/beam/issues/21714 
PulsarIOTest.testReadFromSimpleTopic is very flaky
https://github.com/apache/beam/issues/21708 beam_PostCommit_Java_DataflowV2, 
testBigQueryStorageWrite30MProto failing consistently
https://github.com/apache/beam/issues/21476 WriteToBigQuery Dynamic table 
destinations returns wrong tableId

Re: Regarding Project proposal review and feedback

[Jeff Zhang]

Same question as David,  one idea in my mind is to integrate the beam sql
api with flink table api, this does not exist in the current flink runner.

On Thu, Apr 27, 2023 at 3:46 PM David Morávek  wrote:

> Hi Siddharth,
>
> Thanks for your interest in the Flink Runner for Beam. Reading through the
> project, one thing that immediately strikes me is that there already is a
> Flink runner based on DataStream and Operator (one level below DataStream)
> API in the code base. Are you aware of this? If yes, how does the runner
> you want to introduce differ from the existing one?
>
> Best,
> D.
>
> On Sun, Apr 2, 2023 at 9:41 PM Svetak Sundhar via dev 
> wrote:
>
>> Hi Siddharth,
>> I left some comments as well on the sentiment analysis proposal.
>>
>> Thanks,
>>
>>
>> Svetak Sundhar
>>
>>   Technical Solutions Engineer, Data
>> s vetaksund...@google.com
>>
>>
>>
>> On Sun, Apr 2, 2023 at 1:58 PM Anand Inguva via dev 
>> wrote:
>>
>>> I left some comments on the sentiment analysis proposal.
>>>
>>> Thanks,
>>> Anand
>>>
>>> On Thu, Mar 30, 2023 at 9:59 AM Danny McCormick via dev <
>>> dev@beam.apache.org> wrote:
>>>
 Thanks Siddharth! I left some comments on the sentiment analysis
 proposal, I am probably not the best person to comment on the flink
 datastream api one though.

 Thanks,
 Danny

 On Fri, Mar 24, 2023 at 11:53 PM Siddharth Aryan <
 siddhartharyan...@gmail.com> wrote:

> Hello ,
> I am Siddharth Aryan a undergrad and I am looking forward to someone
> who can help me reviewing my proposal and give me a feedback on the them
> which help me to create a good proposal.
> Here ,I am attaching my both the project proposals:
> >Sentimental Analysis Pipeline with the help of Machine Learnig:
>
> https://docs.google.com/document/d/1U6zcXAWsDCrWlbf14f5VlLqPZFucwXR48tD7mrERW-g/edit?usp=sharing
>
> >Integrating Apache Beam with Flink Datastream API:
>
> https://docs.google.com/document/d/1sQEe9eVuoHX9QWS9Zj5wVl7MLmfk7QO09pjZOsk-TFY/edit?usp=sharing
>
> Best Regards
> Siddharth Aryan
>
> Github :https://github.com/nervoussidd
>


-- 
Best Regards

Jeff Zhang

Re: Regarding Project proposal review and feedback

[David Morávek]

Hi Siddharth,

Thanks for your interest in the Flink Runner for Beam. Reading through the
project, one thing that immediately strikes me is that there already is a
Flink runner based on DataStream and Operator (one level below DataStream)
API in the code base. Are you aware of this? If yes, how does the runner
you want to introduce differ from the existing one?

Best,
D.

On Sun, Apr 2, 2023 at 9:41 PM Svetak Sundhar via dev 
wrote:

> Hi Siddharth,
> I left some comments as well on the sentiment analysis proposal.
>
> Thanks,
>
>
> Svetak Sundhar
>
>   Technical Solutions Engineer, Data
> s vetaksund...@google.com
>
>
>
> On Sun, Apr 2, 2023 at 1:58 PM Anand Inguva via dev 
> wrote:
>
>> I left some comments on the sentiment analysis proposal.
>>
>> Thanks,
>> Anand
>>
>> On Thu, Mar 30, 2023 at 9:59 AM Danny McCormick via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Thanks Siddharth! I left some comments on the sentiment analysis
>>> proposal, I am probably not the best person to comment on the flink
>>> datastream api one though.
>>>
>>> Thanks,
>>> Danny
>>>
>>> On Fri, Mar 24, 2023 at 11:53 PM Siddharth Aryan <
>>> siddhartharyan...@gmail.com> wrote:
>>>
 Hello ,
 I am Siddharth Aryan a undergrad and I am looking forward to someone
 who can help me reviewing my proposal and give me a feedback on the them
 which help me to create a good proposal.
 Here ,I am attaching my both the project proposals:
 >Sentimental Analysis Pipeline with the help of Machine Learnig:

 https://docs.google.com/document/d/1U6zcXAWsDCrWlbf14f5VlLqPZFucwXR48tD7mrERW-g/edit?usp=sharing

 >Integrating Apache Beam with Flink Datastream API:

 https://docs.google.com/document/d/1sQEe9eVuoHX9QWS9Zj5wVl7MLmfk7QO09pjZOsk-TFY/edit?usp=sharing

 Best Regards
 Siddharth Aryan

 Github :https://github.com/nervoussidd

>>>