checkpoint_during_suspend booleanDeprecated: setting this true or false does not have an effect anymore. |
clock_resolution_usecs int64Real-time clock resolution in microseconds. This parameter controls the execution of queries that use the NOW() function. The output of such
queries depends on the real-time clock and can change over time without any external
inputs. If the query uses NOW(), the pipeline will update the clock value and trigger incremental
recomputation at most each clock_resolution_usecs microseconds. If the query does not use
NOW(), then clock value updates are suppressed and the pipeline ignores this setting. It is set to 1 second (1,000,000 microseconds) by default. |
cpu_profiler booleanEnable CPU profiler. The default value is true. |
dev_tweaks objectOptional settings for tweaking Feldera internals. The available key-value pairs change from one version of Feldera to
another, so users should not depend on particular settings being
available, or on their behavior. |
fault_tolerance objectFault-tolerance configuration. The default [FtConfig] (via [FtConfig::default]) disables fault tolerance,
which is the configuration that one gets if [RuntimeConfig] omits fault
tolerance configuration. The default value for [FtConfig::model] enables fault tolerance, as
Some(FtModel::default()). This is the configuration that one gets if
[RuntimeConfig] includes a fault tolerance configuration but does not
specify a particular model. checkpoint_interval_secs int64Interval between automatic checkpoints, in seconds. The default is 60 seconds. Values less than 1 or greater than 3600 will
be forced into that range. | model |
|
hosts integerNumber of DBSP hosts. The worker threads are evenly divided among the hosts. For single-host
deployments, this should be 1 (the default). Multihost pipelines are an enterprise-only preview feature. |
http_workers int64Sets the number of available runtime threads for the http server. In most cases, this does not need to be set explicitly and
the default is sufficient. Can be increased in case the
pipeline HTTP API operations are a bottleneck. If not specified, the default is set to workers. |
init_containersSpecification of additional (sidecar) containers. |
io_workers int64Sets the number of available runtime threads for async IO tasks. This affects some networking and file I/O operations
especially adapters and ad-hoc queries. In most cases, this does not need to be set explicitly and
the default is sufficient. Can be increased in case
ingress, egress or ad-hoc queries are a bottleneck. If not specified, the default is set to workers. |
logging stringLog filtering directives. If set to a valid tracing-subscriber filter, this controls the log
messages emitted by the pipeline process. Otherwise, or if the filter
has invalid syntax, messages at "info" severity and higher are written
to the log and all others are discarded. |
max_buffering_delay_usecs int64Maximal delay in microseconds to wait for min_batch_size_records to
get buffered by the controller, defaults to 0. |
max_parallel_connector_init int64The maximum number of connectors initialized in parallel during pipeline
startup. At startup, the pipeline must initialize all of its input and output connectors.
Depending on the number and types of connectors, this can take a long time.
To accelerate the process, multiple connectors are initialized concurrently.
This option controls the maximum number of connectors that can be initialized
in parallel. The default is 10. |
min_batch_size_records int64Minimal input batch size. The controller delays pushing input records to the circuit until at
least min_batch_size_records records have been received (total
across all endpoints) or max_buffering_delay_usecs microseconds
have passed since at least one input records has been buffered.
Defaults to 0. |
pin_cpus integer[]Optionally, a list of CPU numbers for CPUs to which the pipeline may pin
its worker threads. Specify at least twice as many CPU numbers as
workers. CPUs are generally numbered starting from 0. The pipeline
might not be able to honor CPU pinning requests. CPU pinning can make pipelines run faster and perform more consistently,
as long as different pipelines running on the same machine are pinned to
different CPUs. |
pipeline_template_configmap objectConfiguration for supplying a custom pipeline StatefulSet template via a Kubernetes ConfigMap. Operators can provide a custom StatefulSet YAML that the Kubernetes runner will use when
creating pipeline StatefulSets for a pipeline. The custom template must be stored as the
value of a key in a ConfigMap in the same namespace as the pipeline; set name to the
ConfigMap name and key to the entry that contains the template. Recommendations and requirements:
- Start from the default template and modify it as needed. The default template is present
in ConfigMap named as
<release-name>-pipeline-template, with key pipelineTemplate in the release
namespace and should be used as a reference.
- The template must contain a valid Kubernetes
StatefulSet manifest in YAML form. The
runner substitutes variables in the template before parsing; therefore the final YAML
must be syntactically valid.
- The runner performs simple string substitution for the following placeholders. Please ensure these
placeholders are placed at appropriate location for their semantics:
{id}: pipeline Kubernetes name (used for object names and labels)
{namespace}: Kubernetes namespace where the pipeline runs
{pipeline_executor_image}: container image used to run the pipeline executor
{binary_ref}: program binary reference passed as an argument
{program_info_ref}: program info reference passed as an argument
{pipeline_storage_path}: mount path for persistent pipeline storage
{storage_class_name}: storage class name to use for PVCs (if applicable)
{deployment_id}: UUID identifying the deployment instance
{deployment_initial}: initial desired runtime status (e.g., provisioning)
{bootstrap_policy}: bootstrap policy value when applicable
key stringKey in the ConfigMap containing the pipeline template. If not set, defaults to pipelineTemplate. | name string — REQUIREDName of the ConfigMap containing the pipeline template. |
|
provisioning_timeout_secs int64Timeout in seconds for the Provisioning phase of the pipeline.
Setting this value will override the default of the runner. |
resources objectcpu_cores_max doubleThe maximum number of CPU cores to reserve
for an instance of this pipeline | cpu_cores_min doubleThe minimum number of CPU cores to reserve
for an instance of this pipeline | memory_mb_max int64The maximum memory in Megabytes to reserve
for an instance of this pipeline | memory_mb_min int64The minimum memory in Megabytes to reserve
for an instance of this pipeline | namespace stringKubernetes namespace to use for an instance of this pipeline.
The namespace determines the scope of names for resources created
for the pipeline.
If not set, the pipeline will be deployed in the same namespace
as the control-plane. | service_account_name stringKubernetes service account name to use for an instance of this pipeline.
The account determines permissions and access controls. | storage_class stringStorage class to use for an instance of this pipeline.
The class determines storage performance such as IOPS and throughput. | storage_mb_max int64The total storage in Megabytes to reserve
for an instance of this pipeline |
|
storage objectStorage configuration for a pipeline. backendBackend storage configuration. | cache_mib integerThe maximum size of the in-memory storage cache, in MiB. If set, the specified cache size is spread across all the foreground and
background threads. If unset, each foreground or background thread cache
is limited to 256 MiB. | compression stringPossible values: [default, none, snappy] Storage compression algorithm. | min_step_storage_bytes integerFor a batch of data passed through the pipeline during a single step,
the minimum estimated number of bytes to write it to storage. This is provided for debugging and fine-tuning and should ordinarily be
left unset. A value of 0 will write even empty batches to storage, and
nonzero values provide a threshold. usize::MAX, the default,
effectively disables storage for such batches. If it is set to another
value, it should ordinarily be greater than or equal to
min_storage_bytes. | min_storage_bytes integerFor a batch of data maintained as part of a persistent index during a
pipeline run, the minimum estimated number of bytes to write it to
storage. This is provided for debugging and fine-tuning and should ordinarily be
left unset. A value of 0 will write even empty batches to storage, and nonzero
values provide a threshold. usize::MAX would effectively disable
storage for such batches. The default is 10,048,576 (10 MiB). |
|
tracing boolean |
tracing_endpoint_jaeger stringJaeger tracing endpoint to send tracing information to. |
workers int32Number of DBSP worker threads. Each DBSP "foreground" worker thread is paired with a "background"
thread for LSM merging, making the total number of threads twice the
specified number. The typical sweet spot for the number of workers is between 4 and 16.
Each worker increases overall memory consumption for data structures
used during a step. |