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

[improve][admin,broker] Add option to unloadNamespaceBundle with bundle Affinity broker url #18663

Merged
merged 14 commits into from
Dec 31, 2022

Conversation

vineeth1995
Copy link
Contributor

@vineeth1995 vineeth1995 commented Nov 28, 2022

Motivation

To provide an option for admin to unload namespace bundle with broker url to which the bundle has to be assigned to after the unload.

Modifications

  1. Add an option to provide brokerWebServiceAddress (Ex: https://broker1.com:4443) while unloadingNamespaceBundle in the admin CLI and make corresponding changes in the pulsar-client-admin-api to support this.

  2. Changes in pulsar-broker unloadNamespaceBundle API to accommodate broker url while unloading.

  3. Add functionality in LoadManger implementation to select affinity broker for a bundle while trying to assign unloaded bundle to broker.

Verifying this change

This change added tests and can be verified as follows:

  • Added end to end test to make sure the bundle assignment happens as per the expectation

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

  • Dependencies (add or upgrade a dependency)
  • The public API
  • The schema
  • The default values of configurations
  • The threading model
  • The binary protocol
  • The REST endpoints
  • The admin CLI options
  • Anything that affects deployment

Documentation

  • doc
  • doc-required
  • doc-not-needed
  • doc-complete

Matching PR in forked repository

PR in forked repository:

@github-actions github-actions bot added the doc-not-needed Your PR changes do not impact docs label Nov 28, 2022
@github-actions
Copy link

@vineeth1995 Please select only one documentation label in your PR description.

@vineeth1995 vineeth1995 changed the title Bundle unload [improve][admin,broker] Add option to unloadNamespaceBundle with bundle Affinity broker url Nov 28, 2022
@github-actions github-actions bot added doc-complete Your PR changes impact docs and the related docs have been already added. and removed doc-not-needed Your PR changes do not impact docs labels Nov 28, 2022
@codelipenghui
Copy link
Contributor

@vineeth1995 Thanks for the contribution.
The new feature should start with a proposal https://github.com/apache/pulsar/blob/master/wiki/proposals/PIP.md
So that we can understand the motivation for the API change.

@codecov-commenter
Copy link

codecov-commenter commented Nov 29, 2022

Codecov Report

Merging #18663 (6f94be4) into master (ed33fb3) will increase coverage by 0.09%.
The diff coverage is 23.80%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #18663      +/-   ##
============================================
+ Coverage     47.36%   47.46%   +0.09%     
- Complexity    10716    10733      +17     
============================================
  Files           712      712              
  Lines         69541    69598      +57     
  Branches       7466     7470       +4     
============================================
+ Hits          32941    33034      +93     
+ Misses        32894    32852      -42     
- Partials       3706     3712       +6     
Flag Coverage Δ
unittests 47.46% <23.80%> (+0.09%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
.../apache/pulsar/broker/loadbalance/LoadManager.java 61.11% <ø> (ø)
.../pulsar/broker/loadbalance/ModularLoadManager.java 0.00% <ø> (ø)
...che/pulsar/broker/loadbalance/NoopLoadManager.java 0.00% <0.00%> (ø)
...ache/pulsar/broker/namespace/NamespaceService.java 58.08% <ø> (-0.15%) ⬇️
...pache/pulsar/broker/admin/impl/NamespacesBase.java 63.56% <2.94%> (-0.04%) ⬇️
...broker/loadbalance/impl/SimpleLoadManagerImpl.java 38.42% <20.00%> (-0.39%) ⬇️
...roker/loadbalance/impl/ModularLoadManagerImpl.java 63.06% <40.00%> (-6.07%) ⬇️
...er/loadbalance/impl/ModularLoadManagerWrapper.java 73.91% <70.00%> (-11.46%) ⬇️
.../org/apache/pulsar/broker/admin/v1/Namespaces.java 49.02% <100.00%> (+0.08%) ⬆️
.../org/apache/pulsar/broker/admin/v2/Namespaces.java 59.98% <100.00%> (+2.02%) ⬆️
... and 53 more

Copy link
Contributor

@rdhabalia rdhabalia left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@codelipenghui codelipenghui left a comment

Choose a reason for hiding this comment

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

A proposal is required since the PR is changed the Admin API and introduced a new feature.

@rdhabalia
Copy link
Contributor

@codelipenghui I don't think this will require PIP as it's part of adding a flag in admin API. There are a large number of PRs which must have gone through PIP with similar changes but merge without any explanation. let me give you few examples
#16167
#14680
#12136
#13938

also PR which breaks backward compatibility #10601 was merged without any concerns.
I have many such examples where I see practice by the specific community to discourage people from their contribution and delay their efforts. I would strongly discourage such destructive practices.
There are such bad practices going on in the community and I have many examples. Please let us know if you have any concerns with the PR by adding an option flag if not then you should not BLOCK the PR unnecessarily as it will start -ve and destructive practice in the community and we didn't open source Pulsar for such things.

@rdhabalia
Copy link
Contributor

@codelipenghui I know there were multiple genuine PRs were blocked in past and they were sitting unmerged for a long time for multiple releases. I can clearly see the intention but we should avoid such destructive practice instead we should spend time in constructive efforts as not every contributor is vendor but users/companies are trying to contribute for their business usecases and such practice discourages companies to use Pulsar.

@rdhabalia
Copy link
Contributor

@codelipenghui can you please unblock the PR?

@rdhabalia
Copy link
Contributor

@codelipenghui ping

@rdhabalia
Copy link
Contributor

this PR is blocked for last 3 days and I haven't heard anything from @codelipenghui . can we unblock the PR or dismiss the review? we can't keep following up on the same thing again and again.

@rdhabalia
Copy link
Contributor

@codelipenghui waiting for your reply to remove the blocker? It's not acceptable to block the PR and not replying here.

@codelipenghui
Copy link
Contributor

@codelipenghui I don't think this will require PIP as it's part of adding a flag in admin API. There are a large number of PRs which must have gone through PIP with similar changes but merge without any explanation. let me give you few examples
#16167
#14680
#12136
#13938

also PR which breaks backward compatibility #10601 was merged without any concerns.
I have many such examples where I see practice by the specific community to discourage people from their contribution and delay their efforts. I would strongly discourage such destructive practices.
There are such bad practices going on in the community and I have many examples. Please let us know if you have any concerns with the PR by adding an option flag if not then you should not BLOCK the PR unnecessarily as it will start -ve and destructive practice in the community and we didn't open source Pulsar for such things.

Sorry for the late response.

Yes, this is why I think it's better to have a proposal to avoid we will not introduce any API changes without a proposal in the future. I agree there are many changes to admin APIs without proposals/discussions. But we are on the wrong way, right? More and more people are starting to use Pulsar. We should be more careful about the API changes than ever.

I want to say there have been many CLI, and admin API changes without proposals before. If you just don't think we should not start with this PR(proposal required). It's ok for me. I think I should start a discussion under the mailing list first, not block this PR under an uncleared rule. I see all the PRs you provided are from StreamNative's engineers. Please don't think I mean to facilitate StreamNative engineers.

Here is an example of a proposal that is not required for new metrics.

#18319
#18560

@codelipenghui codelipenghui dismissed their stale review December 7, 2022 03:11

There have been many CLI, and admin API changes without proposals before. It's better to have a discussion under the mailing list first.

@@ -863,6 +866,50 @@ protected BookieAffinityGroupData internalGetBookieAffinityGroup() {
}
}

private void validateLeaderBroker() {
Copy link
Contributor

Choose a reason for hiding this comment

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

It's better to make this async

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we make it async, the result could be indeterministic. If the bundle-broker mapping is not set by the time loadmanager loads the bundle, it will unload the bundle onto wrong broker.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, it's dependent and we don't have to make it async here for this admin-api.

@@ -1443,6 +1447,15 @@ public void doNamespaceBundleSplit() throws Exception {
}
}

@Override
public String setNamespaceBundleAffinity(String bundle, String broker) {
if (broker == null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

StringUtils.isBlank

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed


@Override
public String setNamespaceBundleAffinity(String bundle, String broker) {
if (broker == null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

StringUtils.isBlank

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed

@@ -142,4 +146,12 @@ public void stop() throws PulsarServerException {
}
}

@Override
public String setNamespaceBundleAffinity(String bundle, String broker) {
if (broker == null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

StringUtils.isBlank

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed

@@ -146,4 +146,16 @@ public Set<String> getAvailableBrokers() throws Exception {
public CompletableFuture<Set<String>> getAvailableBrokersAsync() {
return loadManager.getAvailableBrokersAsync();
}

private SimpleResourceUnit buildBrokerResourceUnit (String broker) {
Copy link
Contributor

Choose a reason for hiding this comment

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

One more blank here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed

Copy link
Contributor

@codelipenghui codelipenghui left a comment

Choose a reason for hiding this comment

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

@vineeth1995 @rdhabalia

After reviewing all the changes, the PR introduced a new concept, bundle affinity, right? It's not only a new option for Admin API.

IMO, it should be 2 parts.

  • Namespace bundle affinity
  • Unload the namespace bundle with affinity (or we can just split it into 2 steps, set affinity, unload bundle)

And I don't see the bundleBrokerAffinityMap will be persistent somewhere. The bundle affinity will disappear after the broker restarts?

Sorry, I have to give a request changes here.

@rdhabalia
Copy link
Contributor

And I don't see the bundleBrokerAffinityMap will be persistent somewhere. The bundle affinity will disappear after the broker restarts?

Yes, that's the purpose. we don't want persistent mapping it's useful when you want to debug by moving bundle temporarily to the specific broker. We already have namespace isolation policy for persistent affinity.

IMO, it should be 2 parts.

No, it's connected to each other where you want to unload bundle by setting specific broker affinity for temporary testing and you don't want to keep it persistent. Here, the main idea is to keep it non-persistent for quick testing, which is the main motivation to help users in debugging.

Sorry, I have to give a request changes here.

Let me know if you have any more concern so, we can remove the hold.

@codelipenghui
Copy link
Contributor

@rdhabalia Thanks for the explanation. Clear for me now.

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.

Very good
I generally support this work.
I left one minor comment that is worth to be addressed

log.error("The leader broker url is malformed - {}", leaderBrokerUrl);
throw new RestException(exception);
} catch (ExecutionException | InterruptedException exception) {
log.error("Leader broker not found - {}", leaderBrokerUrl);
Copy link
Contributor

Choose a reason for hiding this comment

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

ExecutionException may mean many things,
We should unwrap the cause

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed

CompletableFuture<LookupResult> result = pulsar().getNamespaceService()
.createLookupResult(leaderBrokerUrl, false, null);
try {
LookupResult lookupResult = result.get();
Copy link
Contributor

Choose a reason for hiding this comment

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

We should always set a timeout, otherwise the thread may be stuck forever

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed

Vineeth added 13 commits December 20, 2022 22:04
@vineeth1995
Copy link
Contributor Author

@eolivelli I addressed your comments.

@rdhabalia rdhabalia requested a review from eolivelli December 25, 2022 06:20
@rdhabalia
Copy link
Contributor

@eolivelli can you remove the blocker?

@eolivelli
Copy link
Contributor

Lgtm

Please rebase.
We moved the website to another repository, can you please send the docs update to the website repository please? @tisonkun maybe can help

@tisonkun
Copy link
Member

Since this is the first case, I made it a demo to be referred to later. Hopefully, we don't have new cases, but we only need to clear the backlog.

@tisonkun
Copy link
Member

Merging...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc-complete Your PR changes impact docs and the related docs have been already added. ready-to-test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants