You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Michael Marshall <mm...@apache.org> on 2022/04/29 04:24:47 UTC

Pulsar Community Meeting Notes 2022/04/28, (8:30 AM PST)

Hi Pulsar Community,

Here are the meeting notes from today's community meeting.

Disclaimer: I am the primary author of these notes. I took the notes
while participating in the meeting discussions. It is possible that I
missed or misunderstood information. If something is misattributed or
misrepresented, please send a correction to this list and consider
updating the Google doc.

Source google doc:
https://docs.google.com/document/d/19dXkVXeU2q_nHmkG8zURjKnYlvD96TbKf5KjYyASsOE

Thanks,
Michael

2022/04/28, (8:30 AM PST)
-   Attendees:
-   Matteo Merli
-   Lari Hotari
-   Michael Marshall
-   Heesung Sohn
-   Aaron Williams
-   Dave Fisher
-   Andrey Yegorov
-   Mattison Chao
-   Massimiliano Mirelli

-   Discussions

-   Dave: announce that the CFPs are open for both ApacheCon and the
Pulsar Summit. The deadlines are in May. There are already 8
submissions for the ApacheCon Pulsar track. Submissions are welcome.

-   Michael: what needs to be done for an Arm docker image
(https://github.com/apache/pulsar/issues/12944)? Matteo: need to get
the go runtime for functions (that is easy). There are going to be
conflicts in the Dockerfile because of removing Python 2. Python wheel
files already have the script to build the Arm and the Intell files.
We just need the Linux Intel and Linux Arm. Ideal state is that a
release will have both images. Matteo doesn’t think CI should worry
about this, but releases should. The build would specify the target
arch. We’ll want to make sure that the release manager’s process is
easy. Michael: is there anything about bookkeeper that should be
optimized? Matteo: there are Linux Intel optimizations for the JNI.
Therefore, it won’t be as fast on Arm. Bookkeeper would need to pack
multiple shared libraries and cross compile for different target arch.
Rocks DB does this. It makes the binary larger. That could be done in
Bookkeeper. That isn’t a docker problem, though. Michael: do we need
bookkeeper 4.15 for an Arm based docker image? Matteo: yes, and that
is because we need it for the right Rocks DB version.

-   Heesung Sohn: Java 17 build upgrade. Adding compatibility tests
for the clients. Can we reuse the shade integration test? Thinking of
adding the github test matrix for these tests. Lari: the recommended
path for adding new tests in GitHub actions is to extend the current
Pulsar CI so that it is an optimized workflow. The goal is to be
efficient with the Apache shared build resources, which are shared
across all Apache projects in GitHub. Heesung Sohn: I’ll add a new job
in the existing workflow. Lari: what type of test is the shade test?
Heesung Sohn: lists test cases. Mostly covers client and server use
cases. Lari: will the client libraries stay Java 8 compatible? Heesung
Sohn: yes.

-   PRs

-   Michael: https://github.com/apache/pulsar/pull/15314. Describes
the nuance of the problem (covered in the PR). Matteo: why are we
using GSON? Also, we should just use the Data annotation, not the
EqualsAnHashcode. Data is probably a better default. Lari: Value is
the version to use for immutable classes. Michael: is load balancing
broken in 2.10.0? Matteo: we do have unit tests covering load
balancing, but it might not cover this case of serialization and
deserialization. There may be a larger problem. The consequence is
random assignment of bundles because all brokers are viewed as equal.
If the cluster becomes out of balance, it’ll be harder to rebalance.

-   BK: https://github.com/apache/bookkeeper/pull/3239 (autorecovery
FYI). Andrey: asks Matteo to take a look to ensure that there are not
adverse side effects for the PR.

-   BK: 4.15.0 rc1 needs fixes but Pulsar upgrade draft PR is here:
https://github.com/apache/pulsar/pull/15142 . Andrey: This is a large
PR, so even though it is a draft, early reviews would be helpful.
Matteo: in looking at the PR, what is the purpose of overriding the
test timeouts in specific test annotations? There are supposed to be
high level test timoutes. Andrey: it didn’t seem to work without that
annotation. Matteo: there is a difference between running tests maven
and with an IDE. Maven has an extra step to add high level timeouts.
Is this ready when we release BK 4.15? Andrey: tests are passing, so
it should be ready, but the PR still needs reviews. Matteo: that lets
us go to the rocks db upgrade and everything will work on M1 Macs.