profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/kasisnu/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Kasisnu kasisnu @grofers http://twitter.com/kasisnu kasisnu.com I work at @grofers Engineering. Come work with us! Or ask me anything about work. DMs on twitter for a quicker response.

fly2abhishek/imagefield_crop_d8 2

This is the D8 port of imagefield_crop module

fly2abhishek/video_d8 2

This is the D8 port of video module

kasisnu/gh-recurse 1

Download all of someone' github repositories

jfarrell/graphite-ng 0

Next generation graphite server

kasisnu/ansible 0

Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy. Avoid writing scripts or custom code to deploy and update your applications — automate in a language that approaches plain English, using SSH, with no agents to install on remote systems. https://docs.ansible.com/ansible/

kasisnu/ansible-role-firefox 0

Simple role for installing Firefox

kasisnu/aurora 0

Mirror of Apache Aurora

kasisnu/aurora-packaging 0

Mirror of Apache Aurora

pull request commentapache/zookeeper

ZOOKEEPER-4214: Update Netty to 4.1.59.Final on Ivy build for 3.5 branch

Now in branch-3.5. Thank you, @frederiko!

frederiko

comment created time in 4 hours

push eventapache/zookeeper

Frederiko Costa

commit sha 15940b14da1bd51cac850db735b7e00c0d8b3e35

ZOOKEEPER-4214: Update Netty to 4.1.59.Final on Ivy build for 3.5 branch On PR #1605 eolivelli requested to also update the Ivy dependency file. This PR address the comment on https://github.com/apache/zookeeper/pull/1605#issuecomment-780793136 Author: Frederiko Costa <frederiko.costa@workday.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1607 from frederiko/ivy-update

view details

push time in 4 hours

pull request commentapache/zookeeper

ZOOKEEPER-4217: add new arg 'func' to handle_socket_error_msg()

This is now in master. Thank you, @smikes!

smikes

comment created time in 4 hours

push eventapache/zookeeper

Sam Mikes

commit sha eafb93ac3edd28ff23b5b08b05e6ead7e44d85c6

ZOOKEEPER-4217: add new arg 'func' to handle_socket_error_msg() Add argument `const char *func` typically initialized with __func__ to include current function name in log message. Author: Sam Mikes <smikes@apple.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1609 from smikes/handle-msg-report-func

view details

push time in 4 hours

PR closed apache/zookeeper

ZOOKEEPER-4217: add new arg 'func' to handle_socket_error_msg()

Add argument const char *func typically initialized with func to include current function name in log message.

+16 -14

1 comment

1 changed file

smikes

pr closed time in 4 hours

pull request commentapache/zookeeper

ZOOKEEPER-4233: dependency-check:check failing - Jetty 9.4.35.v20201120 - CVE-2020-27223

All active branches are affected:

  • master, branch-3.7, branch-3.7.0: This cherry-picks cleanly;
  • branch-3.6: See https://github.com/apache/zookeeper/pull/1624;
  • branch-3.5: See https://github.com/apache/zookeeper/pull/1625.
ztzg

comment created time in 5 hours

PR opened apache/zookeeper

ZOOKEEPER-4233: dependency-check:check failing - Jetty 9.4.35.v20201120 - CVE-2020-27223

The OWASP checker reports that the version of Jetty currently referenced by this branch is vulnerable to a CVE:

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:5.3.0:check (default-cli) on project zookeeper: 
[ERROR] 
[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '0.0': 
[ERROR] 
[ERROR] jetty-server-9.4.35.v20201120.jar: CVE-2020-27223
[ERROR] jetty-http-9.4.35.v20201120.jar: CVE-2020-27223

https://nvd.nist.gov/vuln/detail/CVE-2020-27223 describes it as:

In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of "quality" (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values.

This changeset bumps Jetty to 9.4.38.v20210224, which is the latest as of the commit date.

+173798 -143347

0 comment

1745 changed files

pr created time in 5 hours

PR opened apache/zookeeper

ZOOKEEPER-4233: dependency-check:check failing - Jetty 9.4.35.v20201120 - CVE-2020-27223

What do you know---I encountered a Jetty vulnerability while trying to prepare a new 3.7.0 RC:

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:5.3.0:check (default-cli) on project zookeeper: 
[ERROR] 
[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '0.0': 
[ERROR] 
[ERROR] jetty-server-9.4.35.v20201120.jar: CVE-2020-27223
[ERROR] jetty-http-9.4.35.v20201120.jar: CVE-2020-27223

https://nvd.nist.gov/vuln/detail/CVE-2020-27223 describes it as:

In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of "quality" (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values.

This changeset bumps Jetty to 9.4.38.v20210224, which is the latest as of the commit date.

+1 -1

0 comment

8 changed files

pr created time in 5 hours

PR opened apache/zookeeper

ZOOKEEPER-4233: dependency-check:check failing - Jetty 9.4.35.v20201120 - CVE-2020-27223

What do you know---I encountered a Jetty vulnerability while trying to prepare a new 3.7.0 RC:

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:5.3.0:check (default-cli) on project zookeeper: 
[ERROR] 
[ERROR] One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '0.0': 
[ERROR] 
[ERROR] jetty-server-9.4.35.v20201120.jar: CVE-2020-27223
[ERROR] jetty-http-9.4.35.v20201120.jar: CVE-2020-27223

https://nvd.nist.gov/vuln/detail/CVE-2020-27223 describes it as:

In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of "quality" (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values.

This changeset bumps Jetty to 9.4.38.v20210224, which is the latest as of the commit date.

+1 -1

0 comment

9 changed files

pr created time in 5 hours

pull request commentapache/zookeeper

ZOOKEEPER-2693: Correct the documentation about response to "ruok" 4lw

I have merged this in master to avoid waiting another couple of months :) But @maoling, I think you should reconsider your position!

P.-S. — I noticed (too late) that the ticket # was not quite about this documentation topic, but I suppose it's close enough:

https://issues.apache.org/jira/browse/ZOOKEEPER-2693

nemobis

comment created time in 17 hours

push eventapache/zookeeper

Federico Leva

commit sha f39caf6fd717acced2e8eb2bbdf98e92395858c5

ZOOKEEPER-2693: Correct the documentation about response to "ruok" 4lw Since 5fe68506f, it's no longer true that the server will either respond or not; now it can also respond that it won't obey, with the message that the command "is not executed because it is not in the whitelist", unlike what one gets if the command does not exist at all. Author: Federico Leva <federico.leva@relexsolutions.com> Reviewers: maoling <maoling@apache.org>, Enrico Olivelli <eolivelli@apache.org> Closes #1608 from nemobis/ZOOKEEPER-2693

view details

push time in 17 hours

PR closed apache/zookeeper

ZOOKEEPER-2693: Correct the documentation about response to "ruok" 4lw

Since 5fe68506f, it's no longer true that the server will either respond or not; now it can also respond that it won't obey, with the message that the command "is not executed because it is not in the whitelist", unlike what one gets if the command does not exist at all.

Author: Federico Leva federico.leva@relexsolutions.com

+8 -5

2 comments

1 changed file

nemobis

pr closed time in 17 hours

push eventapache/zookeeper

Mohammad Arshad

commit sha 76269d6d49dd0914f13df6ba069f7445bf44e6f5

ZOOKEEPER-3877: JMX Bean RemotePeerBean should enclose IPV6 host in square bracket same as LocalPeerBean …quare bracket same as LocalPeerBean Author: Mohammad Arshad <arshad@apache.org> Reviewers: Enrico Olivelli <eolivelli@apache.org> Closes #1493 from arshadmohammad/ZOOKEEPER-3877-master (cherry picked from commit 425ee189dcf952fd7a2a38df375ec245dcdfbfc6) Signed-off-by: Mohammad Arshad <arshad@apache.org>

view details

Damien Diederen

commit sha 69efafe8ab5ea833a0c078d190a4958c49f354f9

ZooKeeper 3.7.0: Release notes

view details

push time in 17 hours

push eventapache/zookeeper

Damien Diederen

commit sha 4b8d10e77db0dbda7082f4b3f46678b3acd4d51b

ZooKeeper 3.7.0: Release notes

view details

push time in 17 hours

pull request commentapache/zookeeper

ZOOKEEPER-4220: Potential redundant connection attempts during leader election

Hi @symat, @anmolnar,

I have merged this in master, branch-3.7, and branch-3.7.0. I hope Andor won't mind, and I would gladly add a test later if we come up with a reasonable idea. I have not merged it in 3.5 nor 3.6 so far, as I prefer to wait for Andor's definitive answer when it comes to these "very stable" branches. What do you think?

symat

comment created time in 17 hours

push eventapache/zookeeper

Mate Szalay-Beko

commit sha ba94493c63005b4f7c7efc0aa9c35a2b39c00305

ZOOKEEPER-4220: Potential redundant connection attempts during leader election We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before. In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us. Author: Mate Szalay-Beko <symat@apache.org> Reviewers: Andor Molnar <anmolnar@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1615 from symat/ZOOKEEPER-4220 (cherry picked from commit 6022e03177b21606575152ac323205af3fbbe9d8) Signed-off-by: Damien Diederen <ddiederen@apache.org>

view details

push time in 17 hours

push eventapache/zookeeper

Mate Szalay-Beko

commit sha d862d0749bdc7f798031f24173b55b30d6b88a28

ZOOKEEPER-4220: Potential redundant connection attempts during leader election We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before. In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us. Author: Mate Szalay-Beko <symat@apache.org> Reviewers: Andor Molnar <anmolnar@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1615 from symat/ZOOKEEPER-4220 (cherry picked from commit 6022e03177b21606575152ac323205af3fbbe9d8) Signed-off-by: Damien Diederen <ddiederen@apache.org>

view details

push time in 17 hours

push eventapache/zookeeper

Mate Szalay-Beko

commit sha 6022e03177b21606575152ac323205af3fbbe9d8

ZOOKEEPER-4220: Potential redundant connection attempts during leader election We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before. In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us. Author: Mate Szalay-Beko <symat@apache.org> Reviewers: Andor Molnar <anmolnar@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1615 from symat/ZOOKEEPER-4220

view details

push time in 17 hours

PR closed apache/zookeeper

ZOOKEEPER-4220: Potential redundant connection attempts during leader election

We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before.

In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us.

+1 -1

3 comments

1 changed file

symat

pr closed time in 17 hours

Pull request review commentapache/zookeeper

Install Zookeeper on IBM Cloud

 protected void pRequest2Txn(int type, long zxid, Request request, Record record,             validatePath(path, request.sessionId);             nodeRecord = getRecordForPath(path);             zks.checkACL(request.cnxn, nodeRecord.acl, ZooDefs.Perms.WRITE, request.authInfo, path, null);+            zks.checkQuota(path, nodeRecord.data, setDataRequest.getData(), OpCode.setData);

THREAD_SAFETY_VIOLATION: Read/Write race. Non-private method PrepRequestProcessor.pRequest2Txn(...) indirectly reads without synchronization from server.ZooKeeperServer.RATE_LOGGER.count. Potentially races with write in method PrepRequestProcessor.pRequest(...). Reporting because this access may occur on a background thread. (at-me in a reply with help or ignore)

mahsandu

comment created time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-4199: Avoid thread leak in QuorumRequestPipelineTest

Now also in branch-3.7 and branch-3.7.0. Thanks!

ztzg

comment created time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-4201: C client: Disable SASL deprecation warnings on macOS

Now also in branch-3.7!

ztzg

comment created time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-4200: Widen latency window in WatcherCleanerTest

Now also in branch-3.7!

ztzg

comment created time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-4219: Quota checks break setData in multi transactions

Thanks @ztzg , merged to master and 3.7.

Great; thank you!

It will need to be cherry-picked to 3.7.0 release branch. Ping me Damien if you want me to cherry-pick it to 3.7.0.

Don't worry about it. Cherry-picking has not been 100% consistent on these branches; I will have to sort it out as I prepare the next RC (in a few days) anyway—and will try and keep the sequences as "parallel" as possible as I do so.

Now also in branch-3.7.0. Thanks!

ztzg

comment created time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-4221: Improve the error message when message goes above jute.maxbufer size

Hi @symat, thank you.

@ztzg I merged this to master and branch-3.7. I think this can go to 3.7.0. Do I need to cherry-pick this to some 3.7.0 release branch, or you will cut a new release branch from branch-3.7 later?

Same as #1611 (comment): don't worry about it, as I have to reconcile both branches anyway. I have added this ticket to my list of things to check.

Now also in branch-3.7.0. Thanks!

mariemat

comment created time in 18 hours

push eventapache/zookeeper

Mathieu Marie

commit sha 4b27c62e866740c977837e52bd264c22afbe6376

ZOOKEEPER-4221: Improve the error message when message goes above jute.maxbufer size Author: Mathieu Marie <mmarie@salesforce.com> Reviewers: Damien Diederen <dd@crosstwine.com>, Mate Szalay-Beko <symat@apache.org> Closes #1614 from mariemat/ZOOKEEPER-4221 (cherry picked from commit 94d0c4d8558e1b201665bb9dffd33dacbc7ca945) Signed-off-by: Mate Szalay-Beko <symat@apache.org>

view details

Damien Diederen

commit sha 7a25de288b8cefced3a1b76bcf11ca0eec90864a

ZOOKEEPER-4219: Quota checks break setData in multi transactions Without this patch, a multi() transaction such as the one implemented in ZooKeeperQuotaTest.testMultiCreateThenSetDataShouldWork fails with MarshallingError when 'enforceQuota' is enabled. This happens whenever the node has an associated quota, whether it was exceeded or not. This is due to the server encountering null while trying to access a database node by path--whereas that node only exists as a ChangeRecord in the server's 'outstandingChanges' list: java.lang.NullPointerException at org.apache.zookeeper.server.ZooKeeperServer.checkQuota(ZooKeeperServer.java:2048) at org.apache.zookeeper.server.PrepRequestProcessor.pRequest2Txn(PrepRequestProcessor.java:397) The patch adds an additional 'lastData' parameter to the quota checking function, and passes the data from the ChangeRecord during 'setData' operations. Author: Damien Diederen <dd@crosstwine.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org>, Norbert Kalmar <nkalmar@apache.org> Closes #1611 from ztzg/ZOOKEEPER-4219-quota-multi-setdata (cherry picked from commit eb1569e4fbb55d12fa6211fbd997aa592fcb01af) Signed-off-by: Norbert Kalmar <nkalmar@apache.org>

view details

Damien Diederen

commit sha 6a8c799e0b8ecb083439159f2d70d4e0cb02e722

ZOOKEEPER-4199: Avoid thread leak in QuorumRequestPipelineTest `QuorumRequestPipelineTest` hosts parameterized tests which explicitly call `QuorumBase.setUp(boolean)`. This patch overrides the argument-less `QuorumBase.setUp()` with an empty body, as the former is annotated `BeforeEach`-otherwise causing the runtime to start a fresh 5-ensemble before each test. Without the override, one such extraneous ensemble is created and immediately leaked for each combination of test method + parameters. The test consequently requires 4000+ simultaneous threads to complete, and while Linux happily handles that load, macOS Catalina's per-process limit of 2048 threads effectively causes the JVM to "crash" or lock up. The solution is copied verbatim from another parameterized subclass of `QuorumBase`, `EagerACLFilterTest`. Author: Damien Diederen <dd@crosstwine.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org> Closes #1591 from ztzg/ZOOKEEPER-4199-thread-leak-qrp-test

view details

push time in 18 hours

push eventapache/zookeeper

Damien Diederen

commit sha 5d47a4ea40e4989841738178952025320cd1c30d

ZOOKEEPER-4200: Widen latency window in WatcherCleanerTest `WatcherCleanerTest` performs latency checks which fail when outside of a 20+Xms window. Before this patch, X was 5ms—whereas 30+ms is frequently seen on an i5 Mac Mini running macOS Catalina. This "dumb" patch just widens the window to 20ms, which makes it "work on my machine," but could obviously still fail in a loaded environment or VM. Author: Damien Diederen <dd@crosstwine.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org> Closes #1592 from ztzg/ZOOKEEPER-4200-widen-latency-window

view details

Damien Diederen

commit sha d28153b38799c4516681da7941c50fb94f99935e

ZOOKEEPER-4201: C client: Disable SASL deprecation warnings on macOS This patch works around the numerous deprecation notices added to the CyrusSASL library on macOS. It is a direct "port" of the solution to MESOS-3030, which hit exactly the same problem: https://issues.apache.org/jira/browse/MESOS-3030 https://reviews.apache.org/r/39230/diff/3/ The PR also includes a fix for the the `clockid_t` compilation issue mentioned in the ticket description, but the test suite as a whole remains broken on macOS as its linker does not support the `--wrap` option. Author: Damien Diederen <dd@crosstwine.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org> Closes #1593 from ztzg/ZOOKEEPER-4201-catalina-c-client-fixes

view details

Damien Diederen

commit sha 658a700c14f304319ad06462310b00ecbc89f392

ZOOKEEPER-4199: Avoid thread leak in QuorumRequestPipelineTest `QuorumRequestPipelineTest` hosts parameterized tests which explicitly call `QuorumBase.setUp(boolean)`. This patch overrides the argument-less `QuorumBase.setUp()` with an empty body, as the former is annotated `BeforeEach`-otherwise causing the runtime to start a fresh 5-ensemble before each test. Without the override, one such extraneous ensemble is created and immediately leaked for each combination of test method + parameters. The test consequently requires 4000+ simultaneous threads to complete, and while Linux happily handles that load, macOS Catalina's per-process limit of 2048 threads effectively causes the JVM to "crash" or lock up. The solution is copied verbatim from another parameterized subclass of `QuorumBase`, `EagerACLFilterTest`. Author: Damien Diederen <dd@crosstwine.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org> Closes #1591 from ztzg/ZOOKEEPER-4199-thread-leak-qrp-test

view details

push time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-3781: Create snapshots on followers when snapshot.trust.emp…

Sounds good, thank you.

srdo

comment created time in 18 hours

pull request commentapache/zookeeper

ZOOKEEPER-3781: Create snapshots on followers when snapshot.trust.emp…

Thank you, @srdo! This is now in master, branch-3.7, and branch-3.7.0.

srdo

comment created time in 18 hours

push eventapache/zookeeper

Stig Rohde Døssing

commit sha 679cc2b1015db6a0b41cf9223c826a4b565387e9

ZOOKEEPER-3781: Create snapshots on followers when snapshot.trust.empty is true snapshot.trust.empty is an escape hatch for users upgrading from 3.4.x to later Zookeeper versions, allowing nodes to start with a non-empty transaction log but no snapshot. The intent is for this setting to be enabled for a short while during the upgrade, and then disabled again, as the check it disables is a safety feature. Prior to this PR, a node would only write a snapshot locally if it became leader, or if it had fallen so far behind the leader that the leader sent a SNAP message instead of a DIFF. This made the upgrade process inconvenient, as not all nodes would create a snapshot when snapshot.trust.empty was true, meaning that the safety check could not be flipped back on. This PR makes follower nodes write a local snapshot when they receive NEWLEADER, if they have no local snapshot and snapshot.trust.empty is true. Author: Stig Rohde Døssing <stig@humio.com> Reviewers: Enrico Olivelli <eolivelli@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1581 from srdo/zookeeper-3781 (cherry picked from commit 1214d3bf611d153ae8c3987523da01d3d6c82686) Signed-off-by: Damien Diederen <ddiederen@apache.org>

view details

push time in 18 hours