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

Enable/disable allowAutoTopicCreation per namespace #5395

Closed
sleungtoast opened this issue Oct 16, 2019 · 4 comments · Fixed by #6471
Closed

Enable/disable allowAutoTopicCreation per namespace #5395

sleungtoast opened this issue Oct 16, 2019 · 4 comments · Fixed by #6471
Labels
release/2.5.2 type/feature The PR added a new feature or issue requested a new feature

Comments

@sleungtoast
Copy link

Is your feature request related to a problem? Please describe.
Currently, allowAutoTopicCreation is set as a broker configuration. Generally in my cluster, I want to set that to false to lock down auto topic creation. However, there are still some use cases where topics change a lot and dynamic topic creation would be easier.

Describe the solution you'd like
I want to be able to turn on/off allowAutoTopicCreation in certain namespaces.

Describe alternatives you've considered

  • Add the creation of new topics to our terraform definition and run that tool, but we keep that config in source control and it would be complex and frequently updated (many times a day) in order to create all the topics we need.
@sleungtoast sleungtoast added the type/feature The PR added a new feature or issue requested a new feature label Oct 16, 2019
@huangdx0726
Copy link
Contributor

@sleungtoast You maybe try admin.brokers().updateDynamicConfiguration(“allowAutoTopicCreation”, false);

@sleungtoast
Copy link
Author

@huangdx0726 Hmm that could work, but if my app had admin privileges already, I could just have it create topics as an admin before using them, and I wouldn't have to temporarily turn on auto topic creation just so this single app can do so.
What I need is for a single non-admin user be able to create topics on a namespace, but nobody else can.

@wmccarley
Copy link
Contributor

@sleungtoast I am in a similar situation as you I would love to control this behavior at namespace level. For most of my clients I want allowAutoTopicCreation = false so I can funnel topic creation through a workflow and have an admin review the request etc.. However I have one client that uses only non-persistent topics and needs allowAutoTopicCreation = true. The way I have accomplished this is using namespace isolation policies to force that one client's namespaces to different brokers with different configurations. Not the best solution IMO but it will allow you to accommodate both use cases in one cluster.

@klevy-toast
Copy link
Contributor

We would like to implement this. It looks like it can be done with configs similar to how deduplication can be enabled on a namespace basis: https://pulsar.apache.org/docs/en/pulsar-admin/#namespace-set-deduplication. Would there be any objections to doing this?

sijie pushed a commit that referenced this issue Mar 26, 2020
…de (#6471)

Fixes #5395 

### Motivation

This change introduces a new namespace policy `autoTopicCreationOverride`, which will enable an override of broker `autoTopicCreation` settings on the namespace level. You may keep `autoTopicCreation` disabled for the broker and allow it on a specific namespace using this feature.

### Modifications

- Add new namespace policy: `autoTopicCreationOverride` and associated API / CLI interface for setting and removing. Defaults to non-partitioned type, but also allows partitioned topics.
- Modifies BrokerService: when checking `autoTopicCreation` configuration, the broker first retrieves namespace policies from zookeeper. If the `autoTopicCreationOverride` policy exists for that namespace then it uses those settings. If not, falls back to broker configuration.
- Slight refactor to move `TopicType` enum to pulsar-common and add `autoTopicCreationOverride` to pulsar-common.
jiazhai pushed a commit that referenced this issue May 8, 2020
…de (#6471)

Fixes #5395

This change introduces a new namespace policy `autoTopicCreationOverride`, which will enable an override of broker `autoTopicCreation` settings on the namespace level. You may keep `autoTopicCreation` disabled for the broker and allow it on a specific namespace using this feature.

- Add new namespace policy: `autoTopicCreationOverride` and associated API / CLI interface for setting and removing. Defaults to non-partitioned type, but also allows partitioned topics.
- Modifies BrokerService: when checking `autoTopicCreation` configuration, the broker first retrieves namespace policies from zookeeper. If the `autoTopicCreationOverride` policy exists for that namespace then it uses those settings. If not, falls back to broker configuration.
- Slight refactor to move `TopicType` enum to pulsar-common and add `autoTopicCreationOverride` to pulsar-common.
(cherry picked from commit fdc3a9b)
huangdx0726 pushed a commit to huangdx0726/pulsar that referenced this issue Aug 24, 2020
…override (apache#6471)

Fixes apache#5395 

### Motivation

This change introduces a new namespace policy `autoTopicCreationOverride`, which will enable an override of broker `autoTopicCreation` settings on the namespace level. You may keep `autoTopicCreation` disabled for the broker and allow it on a specific namespace using this feature.

### Modifications

- Add new namespace policy: `autoTopicCreationOverride` and associated API / CLI interface for setting and removing. Defaults to non-partitioned type, but also allows partitioned topics.
- Modifies BrokerService: when checking `autoTopicCreation` configuration, the broker first retrieves namespace policies from zookeeper. If the `autoTopicCreationOverride` policy exists for that namespace then it uses those settings. If not, falls back to broker configuration.
- Slight refactor to move `TopicType` enum to pulsar-common and add `autoTopicCreationOverride` to pulsar-common.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release/2.5.2 type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants