Hi :) For me, it's a bit unclear what it means by not using Docker in e2e tests in K8S context, since K8S require Docker by default
Also, for for K8S test orchestration, wouldn't vanilla Python suffice? It has all the K8S, Docker client libraries supported natively by them Might just need to write a bit of health check scripts on other infras that Flink supports like Kafka, S3 (mock) etc to safely start Flink and perform any blackbox testing On 2020/11/17 15:35:38, Robert Metzger <r...@apache.org> wrote: > Hi all,> > > Since we are currently testing the 1.12 release, and potentially adding> > more automated e2e tests, I would like to bring up our end to end tests for> > discussion.> > > Some time ago, we introduced a Java-based testing framework, with the idea> > of replacing the current bash-based end to end tests.> > Since the introduction of the java-based framework, more bash tests were> > actually added, making a future migration even harder.> > > *For that reason, I would like to propose that we are stopping to add any> > new bash end to end tests to Flink. All new end to end tests must be> > written in Java and rely on the existing testing framework.*> > > For the 1.13 release, I'm trying to find some time to revisit potential> > improvements for the existing java e2e framework (such as using Docker> > images everywhere), as well as a migration plan for the existing bash> > tests. We have a large number of bash e2e tests that are just parameterized> > differently. If we would start migrating them to Java, we could move a> > larger proportion of tests over to the new Java framework, and tackle the> > more involved bash tests later (kerberized yarn, kubernetes, ...).> > > Let me know what you think!> > > Best,> > Robert> > > > PS: If you are wondering why I'm bringing this up now: I'm spending quite a> > lot of time trying to figure out really hard to debug issues with our bash> > testing infra.> > Also, it is very difficult to introduce something generic for all tests> > (such as a test-timeout, using docker as the preferred deployment method> > etc.) since the tests often don't share common tooling.> > Speaking about tooling: there are a lot of utilities everywhere, sometimes> > duplicated, with different features / stability etc.> > I believe bash is not the right tool for a project this size (in terms of> > developers and lines of code)> > -- *This email, including any information it contains and any attachments to it, is confidential and may be privileged. This email is intended only for the use of the named recipient(s). If you are not a named recipient, please notify the sender immediately by replying to this message and delete the original message. You should not disclose or copy this email, any of its contents or any attachments to it. This email may have been transmitted over an unsecure public network and, therefore, Careem does not accept responsibility for its contents or for any damage sustained as a result of viewing its contents or in connection with its transmission. Careem reserves the right to monitor all communications from or to this account.*
