-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[fix][broker] Fix create ns #17864
[fix][broker] Fix create ns #17864
Conversation
Signed-off-by: Zixuan Liu <[email protected]>
4981f0d
to
a1835b0
Compare
Policies nsp = new Policies(); | ||
nsp.replication_clusters = Collections.singleton(config.getClusterName()); | ||
nsr.createPolicies(ns, nsp); | ||
broker.getAdminClient().namespaces().createNamespace(ns.toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't get it, why nsr.createPolicies(ns, nsp);
is ignored?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some policy is ignored because the conf file effects this policy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
What about adding a test case?
I think we should add an integration test, what do you think about that? |
Could you clarify which policies are affected? |
See the PR description. |
If only the number of bundles were affected, could you use another solution? This PR brings a breaking change to the standalone. We need to add an integration test to protect it. |
No.
Good catch. Let me add an integration test for this. |
For how to reproduce it, you can reference the pulsar-test-service-start.sh, which uses standalone-ssl.conf as the config file. In additional, even if
|
Because you didn't set up the |
Policies nsp = new Policies(); | ||
nsp.replication_clusters = Collections.singleton(config.getClusterName()); | ||
nsr.createPolicies(ns, nsp); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not fix it by something like:
nsp.bundles = /* ... */;
It would be more clear for what's the default bundle policy of the standalone and not affected by the PulsarAdmin implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far, I've only found the bundle issue, I'm not sure about the other factors, so using the admin
.
The previous deployment also didn't set up these two configs and it has worked for a long time. |
It's a real-world breaking change, not something like "it's an API that might already be used somewhere". The current semantics have already been applied in the standalone deployment of the C++/Python client tests. I just confirmed that the Golang client tests would also fail after this change. Other ecosystems are not confirmed. But I think it's enough. Breaking change is a breaking change not for "how it should be used", but for "whether it has already been used". |
Signed-off-by: Zixuan Liu <[email protected]>
### Motivation apache#17864 and apache#18837 tried to fix the regression of the namespace bundle policy in standalone by creating the namespace via `PulsarAdmin`. It brings a problem that the namespace would not be created successfully if the authentication of the built-in admin client was not configured. It brings the regression that makes the set up of the C++ client's unit tests in branch-2.11 fail. Because the steps are: - Start a standalone - Update the policy of `public/default` via `pulsar-admin` without creating the namespace ### Modifications Do not use `PulsarAdmin` to create the namespace when starting the standalone. Instead, set the bundle policy according to the `defaultNumberOfNamespaceBundles` config. Add a `testStandaloneWithRocksDB` to test the namespace can still be created even if no broker client authentication is configured. Then move the bundle policy test from `SmokeTest` to this test.
### Motivation apache#15186 changed the behavior of how to create the default namespace. However, it brings a regression that even if the built-in admin didn't have the authentication configured while the standalone enabled the authentication, the namespace could still be created successfully. This PR also changed the deploy script to remove the creation of "public/default" namespace. Instead, it grants the permission to this namespace directly. After apache#17864 and apache#18837, the namespace will be created by the built-in admin again. But the deploy script would fail. ### Modifications Create the default namespace via `pulsar-admin` in the deploy script.
Motivation
The
bundles
policy of the namespace is ignored if the namespace is created directly by theNamespaceResources
, see the logic of admin service:pulsar/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/v2/Namespaces.java
Lines 1956 to 1969 in 9e4daea
Modifications
admin
to create a namespace instead of theNamespaceResources
Documentation
doc-required
(Your PR needs to update docs and you will update later)
doc-not-needed
(Please explain why)
doc
(Your PR contains doc changes)
doc-complete
(Docs have been already added)
Matching PR in forked repository
nodece#4