Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PIP-45: Added BookKeeper metadata adapter based on MetadataStore #12770

Merged
merged 2 commits into from
Dec 1, 2021

Conversation

merlimat
Copy link
Contributor

Motivation

This PR adds an implementation of BK metadata driver that is based on top of MetadataStore API. This will be used to provide a single metadata backend implementation, shared between Pulsar & BookKeeper.

The code has been adapted from the existing ZK provider.

Eventually, at some point it will make sense to have this to live in BK repo, also with MetadataStore API. For now, it's much easier to continue the development in a single place.

@merlimat merlimat added the type/feature The PR added a new feature or issue requested a new feature label Nov 12, 2021
@merlimat merlimat added this to the 2.10.0 milestone Nov 12, 2021
@merlimat merlimat self-assigned this Nov 12, 2021
@merlimat merlimat added doc-not-needed Your PR changes do not impact docs and removed doc-label-missing labels Nov 12, 2021
@apache apache deleted a comment from github-actions bot Nov 12, 2021
Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work.
The patch is huge I have to make another round of review.

It looks like this implementation will be compatible with existing clusters and this is great.
I still haven't figure out how we can setup this new implementation and how we can use it while using tools like BK shell (or bkctl or BKVM....)

long ledgerId;
{
@Cleanup
WriteHandle wh = bkc.newCreateLedgerOp()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a minimal test about opening the ledger in recovery mode?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Added one.

@merlimat
Copy link
Contributor Author

merlimat commented Nov 16, 2021

Great work. The patch is huge I have to make another round of review.

Yes, sorry but there was no easy way to break it down :)

It looks like this implementation will be compatible with existing clusters and this is great.

Yes, it will use ZK in same exact way.

I still haven't figure out how we can setup this new implementation and how we can use it while using tools like BK shell (or bkctl or BKVM....)

This, and the documentation, will come later, but the idea is that you set the BK metadata service url with a metadata-store prefix. eg: metadata-store:zk://localhost:2181

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@eolivelli eolivelli merged commit 9c4f182 into apache:master Dec 1, 2021
Copy link
Contributor

@hangc0276 hangc0276 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!

@merlimat merlimat deleted the pip-45-bk-metadata-store branch December 1, 2021 14:55
}

@Test(dataProvider = "impl")
public void testSimple(String provider, Supplier<String> urlSupplier) throws Exception {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@merlimat This test seems to be very flaky.

Error:  Tests run: 7, Failures: 1, Errors: 0, Skipped: 4, Time elapsed: 1.505 s <<< FAILURE! - in org.apache.pulsar.metadata.bookkeeper.PulsarLedgerAuditorManagerTest
Error:  testSimple(org.apache.pulsar.metadata.bookkeeper.PulsarLedgerAuditorManagerTest)  Time elapsed: 0.04 s  <<< FAILURE!
java.lang.AssertionError: expected:<bookie-1:3181> but was:<null>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:120)
	at org.junit.Assert.assertEquals(Assert.java:146)
	at org.apache.pulsar.metadata.bookkeeper.PulsarLedgerAuditorManagerTest.testSimple(PulsarLedgerAuditorManagerTest.java:93)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:45)
	at org.testng.internal.InvokeMethodRunnable.call(InvokeMethodRunnable.java:73)
	at org.testng.internal.InvokeMethodRunnable.call(InvokeMethodRunnable.java:11)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

that happened in https://github.com/apache/pulsar/runs/4384832543?check_suite_focus=true#step:8:1479

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I just noticed it. Looking at it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think it's a merge conflict. The test always fails with Rocksdb backend implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reported this as #13071

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it because MetadataStoreExtended.create(..) for RocksDB don't share the same file so, they don't sync with each other ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc-not-needed Your PR changes do not impact docs type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants