pub struct Config {
pub http_addr: SocketAddr,
pub high_volume_storage: Storage,
pub long_term_storage: Storage,
pub runtime: Runtime,
pub logging: Logging,
pub sentry: Sentry,
pub metrics: Metrics,
}Expand description
Main configuration struct for the objectstore server.
This is the top-level configuration that combines all server settings including networking, storage backends, runtime, and observability options.
Configuration is loaded with the following precedence (highest to lowest):
- Environment variables (prefixed with
OS__) - YAML configuration file (if provided via
-cflag) - Default values
See individual field documentation for details on each configuration option, including defaults and environment variables.
Fields§
§http_addr: SocketAddrHTTP server bind address.
The socket address (IP and port) where the HTTP server will listen for incoming
connections. Supports both IPv4 and IPv6 addresses. Note that binding to 0.0.0.0
makes the server accessible from all network interfaces.
§Default
0.0.0.0:8888 (listens on all network interfaces, port 8888)
§Environment Variable
OS__HTTP_ADDR
high_volume_storage: StorageStorage backend for high-volume, small objects.
This backend is used for smaller objects in scenarios where high-throughput, low-latency
access with many small objects is desired. Good candidates include Bigtable, local
filesystem (for development), or fast SSDs. Can be set to the same backend as
long_term_storage for simplicity.
Note: Currently, objects up to 1 MiB are stored in this backend, while larger objects
are stored in the long_term_storage. This is subject to
change in the future and more configuration options will be added to influence this
decision.
§Default
Filesystem storage in ./data/high-volume directory
§Environment Variables
OS__HIGH_VOLUME_STORAGE__TYPEfor the backend type. SeeStoragefor available options.
§Example
high_volume_storage:
type: bigtable
project_id: my-project
instance_name: objectstore
table_name: objectstorelong_term_storage: StorageStorage backend for large objects with long-term retention.
This backend is used for larger objects in scenarios with lower throughput and higher
latency requirements. Good candidates include S3, Google Cloud Storage, or other object
storage systems. Can be set to the same backend as high_volume_storage for simplicity.
Note: Currently, objects over 1 MiB are stored in this backend, while smaller objects
are stored in the high_volume_storage. This is subject to
change in the future and more configuration options will be added to influence this
decision.
§Default
Filesystem storage in ./data/long-term directory
§Environment Variables
OS__LONG_TERM_STORAGE__TYPE- Backend type (filesystem, s3compatible, gcs, bigtable)- Additional fields depending on the type (see
Storage)
§Example
long_term_storage:
type: gcs
bucket: my-objectstore-bucketruntime: RuntimeConfiguration of the internal task runtime.
Controls the thread pool size and behavior of the async runtime powering the server.
See Runtime for configuration options.
logging: LoggingLogging configuration.
Controls log verbosity and output format. See Logging for configuration options.
sentry: SentrySentry error tracking configuration.
Optional integration with Sentry for error tracking and performance monitoring.
See Sentry for configuration options.
metrics: MetricsInternal metrics configuration.
Optional configuration for submitting internal metrics to Datadog. See Metrics for
configuration options.
Implementations§
Source§impl Config
impl Config
Sourcepub fn load(path: Option<&Path>) -> Result<Self>
pub fn load(path: Option<&Path>) -> Result<Self>
Loads configuration from the provided arguments.
Configuration is merged in the following order (later sources override earlier ones):
- Default values
- YAML configuration file (if provided in
args) - Environment variables (prefixed with
OS__)
§Errors
Returns an error if:
- The YAML configuration file cannot be read or parsed
- Environment variables contain invalid values
- Required fields are missing or invalid
Trait Implementations§
Source§impl<'de> Deserialize<'de> for Config
impl<'de> Deserialize<'de> for Config
Source§fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
Auto Trait Implementations§
impl Freeze for Config
impl RefUnwindSafe for Config
impl Send for Config
impl Sync for Config
impl Unpin for Config
impl UnwindSafe for Config
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
§impl<T> Instrument for T
impl<T> Instrument for T
§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
§impl<T> IntoRequest<T> for T
impl<T> IntoRequest<T> for T
§fn into_request(self) -> Request<T>
fn into_request(self) -> Request<T>
T in a tonic::Request§impl<L> LayerExt<L> for L
impl<L> LayerExt<L> for L
§fn named_layer<S>(&self, service: S) -> Layered<<L as Layer<S>>::Service, S>where
L: Layer<S>,
fn named_layer<S>(&self, service: S) -> Layered<<L as Layer<S>>::Service, S>where
L: Layer<S>,
Layered].§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the foreground set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red() and
green(), which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg():
use yansi::{Paint, Color};
painted.fg(Color::White);Set foreground color to white using white().
use yansi::Paint;
painted.white();§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the background set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red() and
on_green(), which have the same functionality but
are pithier.
§Example
Set background color to red using fg():
use yansi::{Paint, Color};
painted.bg(Color::Red);Set background color to red using on_red().
use yansi::Paint;
painted.on_red();§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling [Attribute] value.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold() and
underline(), which have the same functionality
but are pithier.
§Example
Make text bold using attr():
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);Make text bold using using bold().
use yansi::Paint;
painted.bold();§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi [Quirk] value.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask() and
wrap(), which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk():
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);Enable wrapping using wrap().
use yansi::Paint;
painted.wrap();§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the [Condition] value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted only when both stdout and stderr are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);