sijie commented on a change in pull request #175: Issue 160: Introduce backward compatibility testing URL: https://github.com/apache/distributedlog/pull/175#discussion_r137129199
########## File path: tests/backward/src/main/java/org/apache/distributedlog/tests/backward/ReaderTest.java ########## @@ -0,0 +1,86 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.distributedlog.tests.backward; + +import static com.google.common.base.Charsets.UTF_8; +import static com.google.common.base.Preconditions.checkArgument; + +import java.net.URI; +import org.apache.distributedlog.DistributedLogConfiguration; +import org.apache.distributedlog.LogRecord; +import org.apache.distributedlog.api.AsyncLogReader; +import org.apache.distributedlog.api.DistributedLogManager; +import org.apache.distributedlog.api.namespace.Namespace; +import org.apache.distributedlog.api.namespace.NamespaceBuilder; +import org.apache.distributedlog.common.concurrent.FutureUtils; +import org.apache.distributedlog.util.Utils; + +/** + * A test program to read records. + */ +public class ReaderTest { Review comment: @leighst You have a very good point about dev/productivity. new test pipepline always introduce new problems. I see what you are concerned about. Let me try to explain more at this topic. The backward compat test is effectively comprised of two part: - how do we maintain the backward compat test code? - how do we execute the backward compat test? I think you are mostly concerned about "how do we execute the backward compat test" (aka whether do we need to maintain a separate ci?). we can easily run the backward compat test as part of mvn build. The approach I am taking is mostly to explore a better solution on how to maintain the test code. Let's take a deep look at two different approaches, A) is the mvn-shaded approach (Apache BookKeeper is using now), B) is the docker approach that I am using here. supposed we are releasing X, and moving the development to version X+1. using A) approach: - first, you have to create a new module called `distributedlog-compat-x` module. it will use version x. (e.g. https://github.com/apache/bookkeeper/tree/master/tests/bookkeeper-server-compat-4.2.0) you need to configure shade rule to rename `org.apache.distributedlog` to `shade.x.org.apache.distributedlog`. - after you have a compat module including version x, you need to add test cases for testing backward compat between versions (most of the time, you might copy the test cases from previous versions and change the versions). image you keep 3 versions as your software EOL (end of lifecycle), you might need to copy the tests for version x and version x-1, version x and version x-2. so in A), the good thing is - it will be run as part of mvn build, the bad thing is we end up copying a lot of tests each time we cut a new release. if we don't have a well-defined software EOL, we end up having a lot of duplicated code for testing compat issues between two versions. The approach B) I am taking now is doing it in a different direction. - if we maintain a standard test utils `WriterTest` and `ReaderTest`, we don't need to copy the code for each release. - for version x, its 'WriterTest' and 'ReaderTest' will be included in the docker image published for this release. - in the development of version x+1, we can easily refer those code without reimporting the previous versions. - if we have a well defined backward compat version matrix, we can have one script for testing all the backward compat versions without changing the script for each release. Hope this explanation make sense. yes. the docker images are built not only for backward-compt testing. they will be also used for benchmark, continuous load testing and even production usage. so all the changes in `distributedlog-image` and `docker` are needed for producing docker images for testing and usage. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
