+1 (non-binding)

On 2021/12/14 17:18:03 Matteo Merli wrote:
> https://github.com/apache/pulsar/issues/13302
> 
> Copying here for quoting convenience
> ----
> 
> 
> 
> 
> ## Motivation
> 
> Pulsar standalone is the "Pulsar in a box" version of a Pulsar cluster, where
> all the components are started within the context of a single JVM process.
> 
> Users are using the standalone as a way to get quickly started with Pulsar or
> in all the cases where it makes sense to have a single node deployment.
> 
> Right now, the standalone is starting by default with many components,
> several of
> which are quite complex, since they are designed to be deployed in a 
> distributed
> fashion.
> 
> ## Goal
> 
> Simplify the components of Pulsar standalone to achieve:
> 
>  1. Reduce complexity
>  2. Reduce startup time
>  3. Reduce memory and CPU footprint of running standalone
> 
> ## Proposed changes
> 
> The proposal here is to change some of the default implementations that are
> used for the Pulsar standalone.
> 
>  1. **Metadata Store implementation** -->
>       Change from ZooKeeper to RocksDB
> 
>  2. **Pulsar functions package backend** -->
>       Change from using DistributedLog to using local filesystem, storing the
>       jars directly in the data folder instead of uploading them into BK.
> 
>  3. **Pulsar functions state store implementation** -->
>       Change the state store to be backed by a MetadataStore based backed,
>       with the RocksDB implementation.
> 
>  4. **Table Service** -->
>       Do not start BK table service by default
> 
> ## Compatibility considerations
> 
> In order to avoid compatibility issues where users have existing Pulsar
> standalone services that they want to upgrade without conflicts, we will
> follow the principle of keeping the old defaults where there is existing
> data on the disk.
> 
> We will add a file, serving the purpose as a flag, in the `data/standalone`
> directory, for example `new-2.10-defaults`.
> 
> If the file is present, or if the data directory is completely missing, we
> will adopt the new set of default configuration settings.
> 
> If the file is not there, we will continue to use existing defaults and we 
> will
> not break the upgrade operation.
> 
> 
> 
> 
> 
> --
> Matteo Merli
> <mme...@apache.org>
> 

Reply via email to