I see that keeping the playground job in the Flink repository has a couple of advantages, among other things that it's easier to keep up to date. However, in particular in the light of the potential repository split where we want to separate connectors from Flink core, it seems very problematic to put the ClickEventCount which depends on Flink's Kafka connector in Flink's distribution. To me it seems that this was the path of least resistance but I'm not sure whether it stays like this. I think it would have been cleaner to separate the playground project from Flink core.
Cheers, Till On Thu, Aug 8, 2019 at 1:28 PM Konstantin Knauf <konstan...@ververica.com> wrote: > Hi Till, > > as Fabian said, we considered the option you mentioned, but in the end > decided that not maintaining a separate images has more advantages. > > In the context of FLIP-42 we are also revisiting the examples in general > and want to clean these up a bit. So, for what it's worth, there will be an > opportunity for revisiting this topic soon. > > Best, > > Konstantin > > > > On Thu, Aug 8, 2019 at 11:43 AM Fabian Hueske <fhue...@gmail.com> wrote: > > > The motivation for including the job as an example is to not have to > > maintain a separate Docker image. > > We would like to use the regular Flink 1.9 image for the playground and > > avoid to maintain an image that is slightly different from the regular > 1.9 > > image. > > > > Maintaining the job in a different repository or somewhere else would > mean, > > that we need to have a proper release cycle for it as well. > > Having it among the other examples means it's included in the regular > > release. > > > > Best, Fabian > > > > > > Am Do., 8. Aug. 2019 um 09:47 Uhr schrieb Till Rohrmann < > > trohrm...@apache.org>: > > > > > Before backporting the playground PR to the release-1.9, I'd like to > > > understand why the ClickEventCount job needs to be part of the Flink > > > distribution. Looking at the example, it seems to only work in > > combination > > > with a Kafka cluster. Since it is not self-contained, it does not add > > much > > > value for a user who does not want to use the playgrounds. Moreover, we > > > already have the StateMachineExample job which can be used to read from > > > Kafka if a Kafka cluster is available. So my question would be why > don't > > we > > > include the example job in the docker images for the playground? This > > would > > > be in my opinion a better separation of concerns. > > > > > > I've cross posted my question on the original PR as well. > > > > > > Cheers, > > > Till > > > > > > On Thu, Aug 8, 2019 at 9:23 AM Kurt Young <ykt...@gmail.com> wrote: > > > > > > > +1 to include this in 1.9.0, adding some examples doesn't look like > new > > > > feature to me. > > > > BTW, I am also trying this tutorial based on release-1.9 branch, but > > > > blocked by: > > > > > > > > git clone --branch release-1.10-SNAPSHOT > > > > g...@github.com:apache/flink-playgrounds.git > > > > > > > > Neither 1.10 nor 1.9 exists in flink-playground yet. > > > > > > > > Best, > > > > Kurt > > > > > > > > > > > > On Thu, Aug 8, 2019 at 3:18 PM Fabian Hueske <fhue...@gmail.com> > > wrote: > > > > > > > > > Hi, > > > > > I worked with Konstantin and reviewed the PR. > > > > > I think the playground is a great way to get started with Flink and > > > > explore > > > > > it's recovery mechanism and unique features like savepoints. > > > > > > > > > > I'm in favor of adding the required streaming example program for > the > > > 1.9 > > > > > release unless there's a good technical argument against it. > > > > > > > > > > Best, Fabian > > > > > > > > > > > > > > > > > -- > > Konstantin Knauf | Solutions Architect > > +49 160 91394525 > > > Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2019 > > > -- > > Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany > > -- > > Ververica GmbH > Registered at Amtsgericht Charlottenburg: HRB 158244 B > Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen >
