> As more people joined the development of Pulsar and more PIPs are > opened, I found the configurations became very large. At the moment > for commit 9917aac, there are 426 configuration items in broker.conf, > which is too many. I agree with you, the configuration of pulsar is too complicated, we should optimize its usage
> > I have an idea that we can split `ServiceConfiguration` into different > configuration classes. We need to ensure version compatibility, so we have to write a lot of unnecessary code and this also means we need multiple configuration files, which seems to only optimize the user experience a little. How about creating a script like pulsar-admin, of course, it only deals with broker configuration changes and searches, etc. We classify the configuration items of broker.conf, and users can search according to specific categories. like managed ledger, offload, transaction, schema etc. ``` ./pulsar-conf broker lookup ./pulsar-conf broker modify ``` Thanks, Bo Yunze Xu <y...@streamnative.io.invalid> 于2022年12月13日周二 20:53写道： > > Hi all, > > As more people joined the development of Pulsar and more PIPs are > opened, I found the configurations became very large. At the moment > for commit 9917aac, there are 426 configuration items in broker.conf, > which is too many. > > ```bash > $ grep "^[^#]" conf/broker.conf | wc -l > 426 > ``` > > For beginners, finding the real useful configs from the `broker.conf` > is hard. For developers, it's also bad. For example, the IDE code > completion works significantly slower for a method of > `ServiceConfiguration` than other classes. > > Let's look at Apache Kafka, there are only 17 configs in the server > configuration file. > > ```bash > kafka_2.13-3.3.1$ grep "^[^#]" config/server.properties | wc -l > 17 > ``` > > I think this difference makes Pulsar far more complicated to customize > than Kafka, or than Pulsar should be. > > I have an idea that we can split `ServiceConfiguration` into different > configuration classes. Some configs that are not commonly used should > be moved into another configuration file. Just a brainstorm, does > anyone else have better ideas? > > Thanks, > Yunze
