+1, we can provide a minimal configuration file to users. It only contains the required config and a few commonly used configs.
The full configuration file can be named `broker.full.conf`, and it is used to provide a reference for users. Thanks, Kai On Dec 13, 2022 at 9:03 PM +0800, Yunze Xu <y...@streamnative.io.invalid>, wrote: > For example, when running a standalone (without TLS enabled), only the > following configs are required: > > ```properties > brokerServicePort=6650 > webServicePort=8080 > allowLoopback=true > clusterName=standalone > managedLedgerDefaultEnsembleSize=1 > managedLedgerDefaultWriteQuorum=1 > managedLedgerDefaultAckQuorum=1 > ``` > > Actually only these two ports and `clusterName` are needed, other > configurations can be configured with a default values for standalone. > However, I found there are over 600 configurations in the > `standalone.conf`: > > ```bash > $ grep "^[^#]" conf/standalone.conf | wc -l > 629 > ``` > > Thanks, > Yunze Xu > > On Tue, Dec 13, 2022 at 8:53 PM Yunze Xu <y...@streamnative.io> wrote: > > > > 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
