Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The bacalhau job executions
command retrieves a list of executions for a specific job based on its ID. This can be essential when tracking the various runs and their respective states for a particular job.
-h
, --help
:
Description: Display help for the executions
command.
--hide-header
:
Description: Do not print the column headers when displaying the results.
--limit uint32
:
Description: Restricts the number of results returned.
Default: 20
--next-token string
:
Description: Uses the specified token for pagination. Useful for fetching the next set of results.
--no-style
:
Description: Removes all styling from the table output, displaying raw data.
--order-by string
:
Description: Orders results based on a specific field. Valid fields are: modify_time
, create_time
, id
, and state
.
--order-reversed
:
Description: Reverses the order of the results. Useful in conjunction with --order-by
.
--output format
:
Description: Specifies the desired output format for the command. Supported values are table
, csv
, json
, and yaml
.
Default: table
--pretty
:
Description: Pretty prints the output. This option is applicable only to json
and yaml
output formats.
--wide
:
Description: Prints full values in the table results without truncating any information.
--api-host string
:
Description: Specifies the host for the client and server to communicate through via REST. If the BACALHAU_API_HOST
environment variable is set, this flag will be ignored.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Determines the port for the client and server to communicate on using REST. If the BACALHAU_API_PORT
environment variable is set, this flag will be ignored.
Default: 1234
--log-mode logging-mode
:
Description: Specifies the desired log format. Supported values include default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Defines the path to the bacalhau repository.
Default: $HOME/.bacalhau
List executions for a specific Job:
Expected output:
Order executions by state for a specific job:
Execute the command:
Expected output:
List executions with YAML output:
Expected output:
The bacalhau job describe
command provides a detailed description of a specific job in YAML format. This description can be particularly useful when wanting to understand the attributes and current status of a specific job. To list all available jobs, the bacalhau job list
command can be used.
-h
, --help
:
Description: Display help for the describe
command.
--output format
:
Description: Specifies the desired output format for the command. Supported values are json
and yaml
.
Default: yaml
--pretty
:
Description: Pretty prints the output. This option is applicable only to json
and yaml
output formats.
--api-host string
:
Description: Specifies the host for the client and server to communicate through via REST. If the BACALHAU_API_HOST
environment variable is set, this flag will be ignored.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Determines the port for the client and server to communicate on using REST. If the BACALHAU_API_PORT
environment variable is set, this flag will be ignored.
Default: 1234
--log-mode logging-mode
:
Description: Specifies the desired log format. Supported values include default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Defines the path to the bacalhau repository.
Default: $HOME/.bacalhau
Describe a Job with Full ID:
Describe a Job with Shortened ID:
Describe a Job with JSON Output:
The bacalhau job logs
command allows users to retrieve logs from a job that has been previously submitted. This command is useful for tracking and debugging the progress and state of a running or completed job.
-f
, --follow
:
Description: This flag allows the user to follow the logs in real-time after fetching the current logs. It provides a continuous stream of log updates, similar to tail -f
in Unix-like systems.
-h
, --help
:
Description: Display help information for the logs
command.
--api-host string
:
Description: Specifies the host for the client and server to communicate through REST. This flag is disregarded if the BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Sets the port for RESTful communication between the client and server. If the BACALHAU_API_PORT
environment variable is available, this flag is ignored.
Default: 1234
--log-mode logging-mode
:
Description: Determines the desired log format. Available options include default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Specifies the path to the bacalhau repository.
Default: $HOME/.bacalhau
Display Logs for a Previously Submitted Job with Full ID:
Command:
Expected Output:
Follow Logs in Real-Time:
Command:
Expected Output:
Display Logs Using a Shortened ID:
Command:
Expected Output:
The bacalhau job
command provides a suite of sub-commands to submit, query, and manage jobs within Bacalhau. Users can deploy jobs, obtain job details, track execution logs, and more.
Description: Retrieves detailed information of a job using its ID.
Usage:
Description: Lists all executions associated with a job, identified by its ID.
Usage:
Description: Enumerates the historical events related to a job, identified by its ID.
Usage:
list:
Description: Provides an overview of all submitted jobs.
Usage:
logs:
Description: Fetches and streams the logs from a currently executing job.
Usage:
run:
Description: Submits a job for execution using either a JSON or YAML configuration file.
Usage:
stop:
Description: Halts a previously submitted job.
Usage:
For comprehensive details on any of the sub-commands, run:
-h
, --help
:
Description: Shows the help information for the job
command.
--api-host string
:
Description: Determines the host for RESTful communication between the client and server. This flag is overlooked if the BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Designates the port for RESTful communication. This flag is bypassed if the BACALHAU_API_PORT
environment variable is active.
Default: 1234
--log-mode logging-mode
:
Description: Chooses the preferred log format. Available choices are: default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Specifies the path to the bacalhau repository.
Default: $HOME/.bacalhau
The bacalhau job list
command provides a listing of all submitted jobs. This command offers an overview of all tasks and processes registered in the system, allowing users to monitor and manage their jobs effectively.
-h
, --help
:
Description: Display help for the list
command.
--hide-header
:
Description: Opts out of printing the column headers in the results.
--labels string
:
Description: Filters jobs by labels. It's designed to function similar to Kubernetes label selectors.
Default: bacalhau_canary != true
--limit uint32
:
Description: Limits the number of results returned.
Default: 10
--next-token string
:
Description: Uses the provided token for pagination.
--no-style
:
Description: Strips all styling from the table output.
--order-by string
:
Description: Organizes results based on a chosen field. Valid fields are id
and created_at
.
--order-reversed
:
Description: Reverses the order of the displayed results.
--output format
:
Description: Dictates the desired output format for the command. Options are table
, csv
, json
, and yaml
.
Default: table
--pretty
:
Description: Offers a more visually pleasing output for json
and yaml
formats.
--wide
:
Description: Presents full values in the table results, preventing truncation.
--api-host string
:
Description: Defines the host for client-server communication via REST. Overridden by the BACALHAU_API_HOST
environment variable, if set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Sets the port for RESTful communication between the client and server. The BACALHAU_API_PORT
environment variable takes precedence if set.
Default: 1234
--log-mode logging-mode
:
Description: Designates the desired log format. Options include default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Points to the bacalhau repository location.
Default: $HOME/.bacalhau
List all jobs:
Execute the command to list all the jobs:
Expected output:
Limit the list to the last two jobs:
Limit the list to display only the last two jobs:
Expected output:
Order the list by creation date in descending order:
Order the jobs by their creation date in a descending manner:
Expected output:
Filter the jobs by specific labels:
Display jobs that have specific labels:
Expected output:
Display the list in JSON format with pretty printing:
Get a limited list of jobs in a formatted JSON output:
Expected output:
The bacalhau job stop
command allows users to terminate a previously submitted job. This is useful in scenarios where there's a need to halt a running job, perhaps due to misconfiguration or changed priorities.
--quiet
:
Description: If provided, the command will not display any output, neither to the standard output (stdout) nor to the standard error (stderr).
-h
, --help
:
Description: Displays help information for the stop
command.
--api-host string
:
Description: Specifies the host used for RESTful communication between the client and server. The flag is disregarded if BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Determines the port for REST communication. If BACALHAU_API_PORT
environment variable is set, this flag will be ignored.
Default: 1234
--log-mode logging-mode
:
Description: Selects the desired log format. Options include: default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Defines the path to the bacalhau repository.
Default: $HOME/.bacalhau
Stop a Specific Job:
If you wish to halt the execution of a job, you can utilize the stop
command. Here's how you can achieve that:
Command:
Expected Output:
Silently Stop a Job:
If you prefer to terminate a job without seeing any verbose feedback or messages, the --quiet
option can be used.
Command:
Expected Output:
The bacalhau job history
command lists the history events of a specific job based on its ID. This feature allows users to track changes, executions, and other significant milestones associated with a particular job.
--event-type string
:
Description: Specifies the type of history events to retrieve. Available options include all
, job
, and execution
.
Default: all
--execution-id string
:
Description: Filters results by a specific execution ID.
-h
, --help
:
Description: Display help for the history
command.
--hide-header
:
Description: Opts out of printing the column headers in the results.
--limit uint32
:
Description: Limits the number of results returned.
--next-token string
:
Description: Uses the provided token for pagination.
--no-style
:
Description: Strips all styling from the table output.
--node-id string
:
Description: Filters the results by a specific node ID.
--order-by string
:
Description: Organizes results based on a chosen field.
--order-reversed
:
Description: Reverses the order of the displayed results.
--output format
:
Description: Dictates the desired output format for the command. Options are table
, csv
, json
, and yaml
.
Default: table
--pretty
:
Description: Offers a more visually pleasing output for json
and yaml
formats.
--wide
:
Description: Presents full values in the table results, preventing truncation.
--api-host string
:
Description: Defines the host for client-server communication via REST. Overridden by the BACALHAU_API_HOST
environment variable, if set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Sets the port for RESTful communication between the client and server. The BACALHAU_API_PORT
environment variable takes precedence if set.
Default: 1234
--log-mode logging-mode
:
Description: Designates the desired log format. Options include default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Points to the bacalhau repository location.
Default: $HOME/.bacalhau
Retrieve the history of a specific job:
Execute the command to get the job history:
Expected output:
Filter the history by event type:
Filter the job history by the event type:
Expected output:
Filter the history by execution ID:
Filter the job history by a specific execution ID:
Expected output:
Retrieve the history in YAML format:
Get the job history in YAML format:
Expected output:
The bacalhau node describe
command offers users the ability to retrieve detailed information about a specific node using its unique identifier.
Using the describe
sub-command under the bacalhau node
umbrella, users can get comprehensive details of a node by providing its ID. This information is crucial for system administrators and network managers to understand the state, specifications, and other attributes of nodes in their infrastructure.
[id]
:
The unique identifier of the node you wish to describe.
-h
, --help
:
Displays the help documentation for the describe
command.
--output format
:
Defines the desired format for the command's output.
Options: "json"
or "yaml"
Default: "yaml"
--pretty
:
When this flag is used, the command will pretty print the output. This is applicable only for outputs in json
and yaml
formats.
--api-host string
:
Specifies the host for client-server communication through REST. This flag is overridden if the BACALHAU_API_HOST
environment variable is set.
Default: "bootstrap.production.bacalhau.org"
--api-port int
:
Designates the port for REST-based communication between client and server. This flag is overlooked if the BACALHAU_API_PORT
environment variable is defined.
Default: 1234
--log-mode logging-mode
:
Determines the log format preference.
Options: 'default','station','json','combined','event'
Default: 'default'
--repo string
:
Points to the bacalhau repository's path.
Default: "
$HOME/.bacalhau"`
Describing a Node with ID nodeID123
:
Describing a Node with Output in JSON Format:
Pretty Printing the Description of a Node:
The bacalhau node approve
command offers administrators the ability to approve the cluster membership for a node using its name.
Using the approve
sub-command under the bacalhau node
umbrella, users can allow a node in the pending state to join the cluster and receive work. This feature is crucial for system administrators to manage the cluster.
[id]
:
The unique identifier of the node you wish to describe.
-h
, --help
:
Displays the help documentation for the describe
command.
-m message
:
A message to be attached to the approval action.
--api-host string
:
Specifies the host for client-server communication through REST. This flag is overridden if the BACALHAU_API_HOST
environment variable is set.
Default: "bootstrap.production.bacalhau.org"
--api-port int
:
Designates the port for REST-based communication between client and server. This flag is overlooked if the BACALHAU_API_PORT
environment variable is defined.
Default: 1234
--log-mode logging-mode
:
Determines the log format preference.
Options: 'default','station','json','combined','event'
Default: 'default'
--repo string
:
Points to the bacalhau repository's path.
Default: "
$HOME/.bacalhau"`
Approve a Node with ID nodeID123
:
Approve a Node with an audit message:
The bacalhau node delete
command offers administrators the ability to remove a node from the cluster using its name.
Using the delete
sub-command, administrators can remove a node from the list of available compute nodes in the cluster. This feature is necessary for the management of the infrastructure.
[id]
:
The unique identifier of the node you wish to describe.
-h
, --help
:
Displays the help documentation for the describe
command.
-m message
:
A message to be attached to the deletion action.
--api-host string
:
Specifies the host for client-server communication through REST. This flag is overridden if the BACALHAU_API_HOST
environment variable is set.
Default: "bootstrap.production.bacalhau.org"
--api-port int
:
Designates the port for REST-based communication between client and server. This flag is overlooked if the BACALHAU_API_PORT
environment variable is defined.
Default: 1234
--log-mode logging-mode
:
Determines the log format preference.
Options: 'default','station','json','combined','event'
Default: 'default'
--repo string
:
Points to the bacalhau repository's path.
Default: "
$HOME/.bacalhau"`
Delete the Node with ID nodeID123
:
Delete a Node with an audit message:
The bacalhau node list
command is designed to provide users with a comprehensive list of network nodes along with details based on specified flags.
The list
sub-command under the bacalhau node
category enumerates information about nodes in the network. It supports various filtering, ordering, and output formatting options, allowing users to tailor the output to their needs.
-h
, --help
:
Show the help message for the list
command.
--hide-header
:
Do not display the column headers in the output.
--filter-approval
:
Only show nodes with the specified approval status. Valid values are: approved
, pending
, rejected
.
--filter-status
:
Only show nodes with the specified state. Valid values are: healthy
, unhealthy
, unknown
.
--labels string
:
Filter nodes based on labels. This follows the filtering format provided by Kubernetes, as shown in their documentation about labels.
--limit uint32
:
Restrict the number of results displayed.
--next-token string
:
Provide the next token for pagination.
--no-style
:
Output the table without any style.
--order-by string
:
Sort the results based on a specific field. Valid sorting fields are: id
, type
, available_cpu
, available_memory
, available_disk
, available_gpu
.
--order-reversed
:
Display the results in reverse order.
--output format
:
Choose the output format. Available options: table
, csv
, json
, yaml
.
Default: table
.
--pretty
:
Enhance the visual appeal of the output. This is applicable only to json
and yaml
formats.
--show strings
:
Determine the column groups to be displayed. Acceptable values are: labels
, version
, features
, capacity
.
Default: labels
, capacity
.
--wide
:
Display full values in the output table, without truncation.
--api-host string
:
Specify the host for client-server communication via REST. This gets ignored if the BACALHAU_API_HOST
environment variable is defined.
Default: "bootstrap.production.bacalhau.org"
.
--api-port int
:
Specify the port for RESTful communication between client and server. Gets overlooked if the BACALHAU_API_PORT
environment variable is set.
Default: 1234
.
--log-mode logging-mode
:
Choose the desired log format.
Options: 'default', 'station', 'json', 'combined', 'event'
.
Default: 'default'
.
--repo string
:
Point to the directory path of the bacalhau repository.
Default: "
$HOME/.bacalhau"`.
Retrieve the list of nodes:
Execute the command to get a list of all nodes:
Expected output:
Filter the list of nodes by labels:
Execute the command to get a list of nodes with specific labels:
Expected output:
Order the list of nodes by available memory:
Execute the command to get the list of nodes ordered by available memory:
Expected output:
Limit the number of nodes displayed and output in JSON format:
Execute the command to get a limited list of nodes in JSON format:
Expected output:
The bacalhau job run
command facilitates the initiation of a job from a file or directly from the standard input (stdin). The command supports both JSON and YAML data formats. This command is particularly useful for quickly executing a job without the need for manual configurations.
--dry-run
:
Description: With this flag, the job will not be submitted. Instead, it will display what would have been submitted, providing a way to preview before actual submission.
-f
, --follow
:
Description: If provided, the command will continuously display the output from the job as it runs.
--id-only
:
Description: On successful job submission, only the Job ID will be printed.
--node-details
:
Description: Displays details of all nodes. Note that this flag is overridden if --id-only
is provided.
--show-warnings
:
Description: Shows any warnings that occur during the job submission.
--wait
:
Description: Waits for the job to finish execution. To set this to false, use --wait=false
Default: true
--wait-timeout-secs int
:
Description: If --wait
is provided, this flag sets the maximum time (in seconds) the command will wait for the job to finish before it terminates.
Default: 600
seconds
-h
, --help
:
Description: Displays help information for the run
command.
--api-host string
:
Description: Specifies the host used for RESTful communication between the client and server. The flag is disregarded if BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Determines the port for REST communication. If BACALHAU_API_PORT
environment variable is set, this flag will be ignored.
Default: 1234
--log-mode logging-mode
:
Description: Selects the desired log format. Options include: default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Defines the path to the bacalhau repository.
Default: $HOME/.bacalhau
Sample Job (job.yaml
)
A sample job used in the following examples is provided below:
This configuration describes a batch job that runs a Docker task. It utilizes the ubuntu:latest
image and executes the command echo Hello Bacalhau!
.
Running a Job using a YAML Configuration:
To run a job with a configuration provided in a job.yaml
file:
Command:
Expected Output:
Running a Job and Following its Logs:
Command:
Expected Output:
Running a Job Without Waiting:
Command:
Expected Output:
Fetching Only the Job ID Upon Submission:
Command:
Expected Output:
Fetching Only the Job ID and Wait for Completion:
Command:
Expected Output:
Running a Job with Node Details:
Command:
Expected Output:
Rerunning a previously submitting job:
Command:
Expected Output:
The bacalhau job run
command also supports templating, which allows users to dynamically inject variables into their job specifications. Additional flags related to templating include:
--no-template
:
Description: Disable the templating feature. When this flag is set, the job spec will be used as-is, without any placeholder replacements.
-E, --template-envs
:
Description: Specify a regular expression pattern for selecting environment variables to be included as template variables in the job spec. e.g. --template-envs ".*"
will include all environment variables.
-V, --template-vars
:
Description: Replace a placeholder in the job spec with a value. e.g. --template-vars foo=bar
Templating is particularly useful when running multiple jobs with varying parameters such as DuckDB query, S3 buckets, prefixes, and time ranges without the need to edit each job specification file manually.
The templating functionality in Bacalhau is built upon the Go text/template package. This powerful library offers a wide range of features for manipulating and formatting text based on template definitions and input variables.
Sample Job Spec with Templating Variables:
Running with Templating:
Defining Flag Multiple Times:
Disabling Templating:
You can also use environment variables for templating:
Passing A Subset of Environment Variables:
To preview the final templated job spec without actually submitting the job, you can use the --dry-run
flag:
This will output the processed job specification, showing you how the placeholders have been replaced with the provided values.
This is an ops job that runs on all nodes that match the job selection criteria. It accepts duckdb query variable, and two optional start-time and end-time variables to define the time range for the query.
To run this job, you can use the following command:
This is a batch job that runs on a single node. It accepts the duckdb query variable, and four other variables to define the S3 bucket, prefix, and pattern for the logs and the AWS region.
To run this job, you can use the following command:
The bacalhau node
command provides a set of sub-commands to query and manage node-related information within Bacalhau. With these tools, users can access specific details about nodes, list all network nodes, and more.
:
Description: Approves a single node to join the cluster.
Usage:
:
Description: Deletes a node from the cluster using its ID.
Usage:
:
Description: Retrieves detailed information of a node using its ID.
Usage:
:
Description: Lists the details of all nodes present in the network.
Usage:
:
Description: Reject a specific node's request to join the cluster.
Usage:
For comprehensive details on any of the sub-commands, run:
-h
, --help
:
Description: Shows the help information for the node
command.
--api-host string
:
Description: Specifies the host for RESTful communication between the client and server. The flag will be ignored if the BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Designates the port for RESTful communication. The flag will be bypassed if the BACALHAU_API_PORT
environment variable is active.
Default: 1234
--log-mode logging-mode
:
Description: Chooses the preferred log format. Available choices are: default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Specifies the path to the bacalhau repository.
Default: /Users/walid/.bacalhau
For more detailed information about the Go text/template library and its syntax, please refer to the official documentation: .
The bacalhau node reject
command offers administrators the ability to reject a compute node's request to join the cluster.
Using the reject
sub-command, administrators can reject a node in the pending state from joining the cluster and receiving work. This feature is crucial for system administrators to manage the cluster and will stop the node from taking part in the cluster until approved.
[id]
:
The unique identifier of the node you wish to describe.
-h
, --help
:
Displays the help documentation for the describe
command.
-m message
:
A message to be attached to the rejection action.
--api-host string
:
Specifies the host for client-server communication through REST. This flag is overridden if the BACALHAU_API_HOST
environment variable is set.
Default: "bootstrap.production.bacalhau.org"
--api-port int
:
Designates the port for REST-based communication between client and server. This flag is overlooked if the BACALHAU_API_PORT
environment variable is defined.
Default: 1234
--log-mode logging-mode
:
Determines the log format preference.
Options: 'default','station','json','combined','event'
Default: 'default'
--repo string
:
Points to the bacalhau repository's path.
Default: "
$HOME/.bacalhau"`
Reject a Node with ID nodeID123
:
Reject a Node with an audit message:
The bacalhau agent node
command retrieves information about the agent's node, providing insights into the agent's environment and aiding in debugging.
-h
, --help
:
Displays help information for the node
sub-command.
--output format
:
Defines the output format (either JSON or YAML).
Options: json
, yaml
Default: yaml
--pretty
:
Beautifies the output when using JSON or YAML formats.
--api-host string
:
The host for REST communication. Overrides the BACALHAU_API_HOST
environment variable.
Default: bootstrap.production.bacalhau.org
--api-port int
:
The port for REST communication. Overridden if BACALHAU_API_PORT
environment variable is set.
Default: 1234
--log-mode logging-mode
:
Specifies the log format. Choices are: default
, station
, json
, combined
, event
.
Default: default
--repo string
:
Path to the bacalhau repository.
Default: ``$HOME/.bacalhau`
Retrieve Node Information in Default Format (YAML)
Retrieve Node Information in JSON Format
Retrieve Node Information in Pretty-printed JSON Format
The bacalhau agent alive
command provides information about the agent's liveness and health. This is essential for monitoring and ensuring that the agent is active and functioning correctly.
-h
, --help
:
Description: Displays help information for the alive
sub-command.
--output format
:
Description: Determines the format in which the output is displayed. Available formats include JSON and YAML.
Options: json
, yaml
Default: yaml
--pretty
:
Description: Formats the output for enhanced readability. This flag is relevant only when using JSON or YAML output formats.
--api-host string
:
Description: Specifies the host used for RESTful communication between the client and server. The flag is disregarded if the BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Specifies the port for REST communication. If the BACALHAU_API_PORT
environment variable is set, this flag will be ignored.
Default: 1234
--log-mode logging-mode
:
Description: Sets the desired log format. Options are: default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Defines the path to the bacalhau repository.
Default: ``$HOME/.bacalhau`
Basic Usage:
Command:
Output:
Output in JSON format:
Command:
Output:
The bacalhau agent
command is a parent command that offers sub-commands to query information about the Bacalhau agent. This can be useful for debugging, monitoring, or managing the agent's behavior and health.
Description: Retrieves the agent's liveness and health information. This can be helpful to determine if the agent is running and healthy.
Usage:
node:
Description: Gathers the agent's node-related information. This might include details about the machine or environment where the agent is running, available resources, supported engines, etc.
Usage:
Description: Retrieves the Bacalhau version of the agent. This can be beneficial for ensuring compatibility or checking for updates.
Usage:
For more detailed information on any of the sub-commands, you can use the command:
-h
, --help
:
Description: Displays help information for the agent
command.
--api-host string
:
Description: Specifies the host used for RESTful communication between the client and server. The flag is disregarded if the BACALHAU_API_HOST
environment variable is set.
Default: bootstrap.production.bacalhau.org
--api-port int
:
Description: Specifies the port for REST communication. If the BACALHAU_API_PORT
environment variable is set, this flag will be ignored.
Default: 1234
--log-mode logging-mode
:
Description: Sets the desired log format. Options are: default
, station
, json
, combined
, and event
.
Default: default
--repo string
:
Description: Defines the path to the bacalhau repository.
Default: ``$HOME/.bacalhau`
The bacalhau config
command is a parent command that offers sub-commands to modify and query information about the Bacalhau config. This can be useful for debugging, monitoring, or managing the nodes configuration.
list:
Description: Lists the configuration keys and values of the bacalhau node. This command is useful for understanding how configuration keys map to their respective values, aiding in the use of the bacalhau config set
command.
Usage:
set:
Description: Sets a value in the bacalhau node's configuration file. This command is used to modify the configuration file that the bacalhau node will reference for its settings.
Usage:
The bacalhau agent version
command is used to obtain the version of the bacalhau agent.
Using this command, users can quickly retrieve the version of the agent, allowing them to confirm the specific release of the software they are using.
-h
, --help
:
Show help for the version
command.
--output format
:
Defines the output format of the command's results. Accepted formats include "json" and "yaml".
--pretty
:
Used for pretty printing the output, enhancing readability. This flag is applicable only for the "json" and "yaml" output formats.
--api-host string
:
Designates the host for client-server communication via REST. If the BACALHAU_API_HOST
environment variable is present, this flag will be disregarded.
Default: "bootstrap.production.bacalhau.org"
--api-port int
:
Defines the port for client-server communication through REST. This flag becomes irrelevant if the BACALHAU_API_PORT
environment variable is specified.
Default: 1234
--log-mode logging-mode
:
Specifies the desired logging format.
Options: 'default','station','json','combined','event'
Default: 'default'
--repo string
:
Indicates the path to the bacalhau repository.
Default: "
$HOME/.bacalhau"`
Retrieve the agent version:
Execute the command to get the agent version:
Expected output:
Retrieve the agent version in JSON format:
Expected output:
Retrieve the agent version in Pretty-printed JSON format:
Expected output:
Note that in version 1.4.0 API logic and endpoints have changed. Check out the release notes and updated API description in the API documentation section.
Welcome to the official API documentation for Bacalhau. This guide provides a detailed insight into Bacalhau's RESTful HTTP APIs and demonstrates how to make the most out of them.
Bacalhau prioritizes an "API-first" design, enabling users to interact with their deployed systems programmatically. In the v1.4.0
the API model was changed to include only two endpoints, focused on orchestrating, querying and managing your network nodes and jobs. Each endpoint has a clear, separate environment and goal, allowing to manage coordination between nodes, jobs, and executions more effectively.
Endpoint Prefix: All APIs are versioned and prefixed with /api/v1
.
Default Port: By default, Bacalhau listens on port 1234
.
The Majority of Bacalhau’s functionality is channeled through the Orchestrator
endpoint and its operations. It handles user requests and schedules and it is critical for creating, managing, monitoring, and analyzing jobs within Bacalhau. It also provides mechanisms to query information about the nodes in the cluster.
Here’s the job submission format, where you can tag a YAML file with the job specifications or input the commands with your CLI
This endpoint offers a convenient route to collate detailed information about the Bacalhau node you're interacting with, whether it's acting as the orchestrator or a compute node. It provides you with insights into the node's health, capabilities, and the deployed Bacalhau version.
Here’s the command structure for querying your current node. You can check on its status and collate information on its health and capabilities:
To handle large datasets, Bacalhau supports pagination. Users can define the limit
in their request and then utilize the next_token
from the response to fetch subsequent data chunks.
To sort the results of list-based queries, use the order_by
parameter. By default, the list will be sorted in ascending order. If you want to reverse it, use the reverse
parameter. Note that the fields available for sorting might vary depending on the specific API endpoint.
By default, Bacalhau's APIs provide a minimized JSON response. If you want to view the output in a more readable format, append pretty
to the query string.
Being RESTful in nature, Bacalhau's API endpoints rely on standard HTTP methods to perform various actions:
GET: Fetch data.
PUT: Update or create data.
DELETE: Remove data.
The behavior of an API depends on its HTTP method. For example, /api/v1/orchestrator/jobs
:
GET: Lists all jobs.
PUT: Submits a new job.
DELETE: Stops a job.
Understanding HTTP response codes is crucial. A 2xx
series indicates a successful operation, 4xx
indicates client-side errors, and 5xx
points to server-side issues. Always refer to the message accompanying the code for more information.
Since /api/v1/requester/*
was changed to /api/v1/orchestrator/
in v1.4.0
, all /api/v1/requester/*
requests will result in 410 error.
The bacalhau config list
command lists the configuration keys and values of the bacalhau node. This command is useful for understanding how configuration keys map to their respective values, aiding in the use of the bacalhau config set
command.
Note: Configuration values displayed by this command represent the settings that will be applied when the bacalhau node is next restarted. It is important to note that these values may not reflect the current operational configuration of an active bacalhau node. The displayed configuration is relevant and accurate for a node that is either not currently running or that has been restarted after the execution of this command.
-h
, --help
:
Description: Displays help information for the list
sub-command.
--hide-header
:
Description: Do not print the column headers when displaying the results.
Default: false
--no-style
:
Description: Removes all styling from the table output, displaying raw data.
Default: false
--output format
:
Description: Determines the format in which the output is displayed. Available formats include Table, JSON, and YAML.
Options: json
, yaml
, table
Default: table
--pretty
:
Description: Formats the output for enhanced readability. This flag is relevant only when using JSON or YAML output formats.
Default: true
--wide
:
Description: Prints full values in the table results without truncating any information.
Default: false
Basic Usage:
Command:
Output:
Output in JSON format:
Command:
Output:
The bacalhau config set
command sets a value in the bacalhau node's configuration file. This command is used to modify the configuration file that the bacalhau node will reference for its settings. Key names in the configuration are case-insensitive. Additionally, the command validates the value being set based on the type of the configuration key, ensuring that only appropriate and valid configurations are applied.
Note: Changes made using this command will be applied to the configuration file, but they do not immediately affect the running configuration of an active bacalhau node. The modifications will take effect only after the node is restarted.
-h
, --help
:
Description: Displays help information for the set
sub-command.
Example of invalid logging mode value
Example of invalid time duration value
Nodes API provides a way to query information about the nodes in the cluster.
Endpoint: GET /api/v1/orchestrator/nodes/:nodeID
Retrieve information about a specific node.
Parameters:
:nodeID
: Identifier of the node to describe. (e.g. QmUDAXvv31WPZ8U9CzuRTMn9iFGiopGE7rHiah1X8a6PkT
)
Response:
Node: Detailed information about the requested node.
Example:
Endpoint: GET /api/v1/orchestrator/nodes
Retrieve a list of nodes.
Parameters:
limit
: Set the maximum number of jobs to return. Default is set to 10.
next_token
: Utilize this parameter for pagination continuation.
order_by
: Determine the ordering of jobs. Choose between id
, type
, available_cpu
, available_memory
, available_disk
or available_gpu
. (default is id
).
reverse
: Opt to reverse the default order of displayed jobs.
Response:
Nodes: List of matching nodes.
NextToken (string)
: Pagination token.
Example:
Find two linux nodes with most available Memory
Job APIs enables creating, managing, monitoring, and analyzing jobs in Bacalhau
Endpoint: GET /api/v1/orchestrator/jobs/:jobID
Retrieve the specification and current status of a particular job.
Parameters:
jobID
: Identifier of the job to describe. This can be full ID of the job (e.g. j-28c08f7f-6fb0-48ed-912d-a2cb6c3a4f3a
) or just the short format (e.g. j-28c08f7f
) if it's unique.
Response:
Job: Specification for the requested .
Example:
Endpoint: GET /api/v1/orchestrator/jobs
Retrieve a list of jobs.
Parameters:
namespace
: Specify a namespace to filter the jobs. Use *
to display jobs from all namespaces.
limit
: Set the maximum number of jobs to return. Default is set to 10.
next_token
: Utilize this parameter for pagination continuation.
order_by
: Determine the ordering of jobs. Choose between id
or create_time
(default is create_time
).
reverse
: Opt to reverse the default order of displayed jobs.
Response:
NextToken (string)
: Pagination token.
Example:
List jobs with limit set to 3:
List with label filtering
Endpoint: PUT /api/v1/orchestrator/jobs
Submit a new job for execution.
Request Body:
Response:
JobID (string)
: Identifier for the new job.
EvaluationID (string)
: Identifier for the evaluation to schedule the job.
Warnings (string[])
: Any warnings during job submission.
Example:
Endpoint: DELETE /api/v1/orchestrator/jobs/:jobID
Terminate a specific job asynchronously.
Parameters:
:jobID
: Identifier of the job to describe. This can be full ID of the job (e.g. j-28c08f7f-6fb0-48ed-912d-a2cb6c3a4f3a
) or just the short format (e.g. j-28c08f7f
) if it's unique.
reason
: A message for debugging and traceability.
Response:
EvaluationID (string)
: Identifier for the evaluation to stop the job.
Example:
Endpoint: GET /api/v1/orchestrator/jobs/:jobID/history
Retrieve historical events for a specific job.
Parameters:
since
: Timestamp to start (default: 0).
event_type
: Filter by event type: job
, execution
, or all
(default).
execution_id
: Filter by execution ID.
node_id
: Filter by node ID.
limit
: Maximum events to return.
next_token
: For pagination.
Response:
History: List of matching historical events.
NextToken (string)
: Pagination token.
Example:
List events for a specific execution
Endpoint: GET /api/v1/orchestrator/jobs/:jobID/executions
Retrieve all executions for a particular job.
Parameters:
limit
: Maximum executions to return.
next_token
: For pagination.
order_by
: Order by modify_time
(default), create_time
, id
, state
.
reverse
: Reverse the order.
Response:
Executions: List of relevant executions.
NextToken (string)
: Pagination token.
Example
List executions for a batch job with 3 executions (i.e. count=3
)
Endpoint: GET /api/v1/orchestrator/jobs/:jobID/results
Fetch results published by all executions for the defined job. Applicable only for batch
and ops
jobs.
Response:
Results: List of all published results.
NextToken (string)
: Pagination token.
Example:
labels
: Use label-based criteria to filter nodes. See for usage details.
labels
: Use label-based criteria to filter jobs. See for usage details.
: List of matching jobs.
: JSON definition of the job.
Result of a job that used the :
The Labels
block within a Job
specification plays a crucial role in Bacalhau, serving as a mechanism for filtering jobs. By attaching specific labels to jobs, users can quickly and effectively filter and manage jobs via both the Command Line Interface (CLI) and Application Programming Interface (API) based on various criteria.
Labels
ParametersLabels are essentially key-value pairs attached to jobs, allowing for detailed categorizations and filtrations. Each label consists of a Key
and a Value
. These labels can be filtered using operators to pinpoint specific jobs fitting certain criteria.
Jobs can be filtered using the following operators:
in
: Checks if the key's value matches any within a specified list of values.
notin
: Validates that the key's value isn’t within a provided list of values.
exists
: Checks for the presence of a specified key, regardless of its value.
!
: Validates the absence of a specified key. (i.e., DoesNotExist)
gt
: Checks if the key's value is greater than a specified value.
lt
: Checks if the key's value is less than a specified value.
= & ==
: Used for exact match comparisons between the key’s value and a specified value.
!=
: Validates that the key’s value doesn't match a specified value.
Filter jobs with a label whose key is "environment" and value is "development":
Filter jobs with a label whose key is "version" and value is greater than "2.0":
Filter jobs with a label "project" existing:
Filter jobs without a "project" label:
Job Management: Enables efficient management of jobs by categorizing them based on distinct attributes or criteria.
Automation: Facilitates the automation of job deployment and management processes by allowing scripts and tools to target specific categories of jobs.
Monitoring & Analytics: Enhances monitoring and analytics by grouping jobs into meaningful categories, allowing for detailed insights and analysis.
The Labels
block is instrumental in the enhanced management, filtering, and operation of jobs within Bacalhau. By understanding and utilizing the available operators and label parameters effectively, users can optimize their workflow, automate processes, and achieve detailed insights into their jobs.
A Job
represents a discrete unit of work that can be scheduled and executed. It carries all the necessary information to define the nature of the work, how it should be executed, and the resources it requires.
job
ParametersName (string : <optional>)
: A logical name to refer to the job. Defaults to job ID.
Namespace (string: "default")
: The namespace in which the job is running. ClientID
is used as a namespace in the public demo network.
Type (string: <required>)
: The type of the job, such as batch
, ops
, daemon
or service
. You can learn more about the supported jobs types in the Job Types guide.
Priority (int: 0
): Determines the scheduling priority.
Count (int: <required)
: Number of replicas to be scheduled. This is only applicable for jobs of type batch
and service
.
Meta (
Meta
: nil)
: Arbitrary metadata associated with the job.
Labels (
Label
[] : nil)
: Arbitrary labels associated with the job for filtering purposes.
Constraints (
Constraint
[] : nil)
: These are selectors which must be true for a compute node to run this job.
Tasks (
Task
[] : <required>)
:: Task associated with the job, which defines a unit of work within the job. Today we are only supporting single task per job, but with future plans to extend this.
The following parameters are generated by the server and should not be set directly.
ID (string)
: A unique identifier assigned to this job. It's auto-generated by the server and should not be set directly. Used for distinguishing between jobs with similar names.
State (
State
)
: Represents the current state of the job.
Version (int)
: A monotonically increasing version number incremented on job specification update.
Revision (int)
: A monotonically increasing revision number incremented on each update to the job's state or specification.
CreateTime (int)
: Timestamp of job creation.
ModifyTime (int)
: Timestamp of last job modification.
A Constraint
represents a condition that must be met for a compute node to be eligible to run a given job. Operators have the flexibility to manually define node labels when initiating a node using the bacalhau serve command. Additionally, Bacalhau boasts features like automatic resource detection and dynamic labeling, further enhancing its capability.
By defining constraints, you can ensure that jobs are scheduled on nodes that have the necessary requirements or conditions.
Constraint
Parameters:Key: The name of the attribute or property to check on the compute node. This could be anything from a specific hardware feature, operating system version, or any other node property.
Operator: Determines the kind of comparison to be made against the Key
's value, which can be:
in
: Checks if the Key's value exists within the provided list of values.
notin
: Ensures the Key's value doesn't match any in the provided list of values.
exists
: Verifies that a value for the specified Key is present, regardless of its actual value.
!
: Confirms the absence of the specified Key. i.e DoesNotExist
gt
: Assesses if the Key's value is greater than the provided value.
lt
: Assesses if the Key's value is less than the provided value.
=
& ==
: Both are used to compare the Key's value for an exact match with the provided value.
!=
: Ensures the Key's value is not the same as the provided value.
Values (optional): A list of values that the node attribute, specified by the Key
, is compared against using the Operator
. This is not needed for operators like exists
or !
.
Consider a scenario where a job should only run on nodes with a GPU and an operating system version greater than 2.0
. The constraints for such a requirement might look like:
In this example, the first constraint checks if the node has a GPU, the second constraint ensures the OS is linux, and deployed in eu-west-1 or eu-west-2`.
Constraints are evaluated as a logical AND, meaning all constraints must be satisfied for a node to be eligible.
Using too many specific constraints can lead to a job not being scheduled if no nodes satisfy all the conditions.
It's essential to balance the specificity of constraints with the broader needs and resources available in the cluster.
An InputSource
defines where and how to retrieve specific artifacts needed for a Task
, such as files or data, and where to mount them within the task's context. This ensures the necessary data is present before the task's execution begins.
Bacalhau's InputSource
natively supports fetching data from remote sources like S3 and IPFS and can also mount local directories. It is intended to be flexible for future expansion.
InputSource
Parameters:Source (
SpecConfig
: <required>)
: Specifies the origin of the artifact, which could be a URL, an S3 bucket, or other locations.
Alias (string: <optional>)
: An optional identifier for this input source. It's particularly useful for dynamic operations within a task, such as dynamically importing data in WebAssembly using an alias.
Target (string: <required>)
: Defines the path inside the task's environment where the retrieved artifact should be mounted or stored. This ensures that the task can access the data during its execution.
In this example, the first input source fetches data from an S3 bucket and mounts it at /my_s3_data
within the task. The second input source mounts a local directory at /my_local_data
and allows the task to read and write data to it.
In both the Job
and Task
specifications within Bacalhau, the Meta
block is a versatile element used to attach arbitrary metadata. This metadata isn't utilized for filtering or categorizing jobs; there's a separate Labels
block specifically designated for that purpose. Instead, the Meta
block is instrumental for embedding additional information for operators or external systems, enhancing clarity and context.
Meta
Parameters in Job and Task SpecsThe Meta
block is comprised of key-value pairs, with both keys and values being strings. These pairs aren't constrained by a predefined structure, offering flexibility for users to annotate jobs and tasks with diverse metadata.
Users can incorporate any arbitrary key-value pairs to convey descriptive information or context about the job or task.
project: Identifies the associated project.
version: Specifies the version of the application or service.
owner: Names the responsible team or individual.
environment: Indicates the stage in the development lifecycle.
Beyond user-defined metadata, Bacalhau automatically injects specific metadata keys for identification and security purposes.
bacalhau.org/requester.id: A unique identifier for the orchestrator that handled the job.
bacalhau.org/requester.publicKey: The public key of the requester, aiding in security and validation.
bacalhau.org/client.id: The ID for the client submitting the job, enhancing traceability.
Identification: The metadata aids in uniquely identifying jobs and tasks, connecting them to their originators and executors.
Context Enhancement: Metadata can supplement jobs and tasks with additional data, offering insights and context that aren't captured by standard parameters.
Security Enhancement: Auto-generated keys like the requester's public key contribute to the secure handling and execution of jobs and tasks.
While the Meta
block is distinct from the Labels
block used for filtering, its contribution to providing context, security, and traceability is integral in managing and understanding the diverse jobs and tasks within the Bacalhau ecosystem effectively.
The Network
object offers a method to specify the networking requirements of a Task
. It defines the scope and constraints of the network connectivity based on the demands of the task.
Network
Parameters:Type (string: "None")
: Indicates the network configuration's nature. There are several network modes available:
None
: This mode implies that the task does not necessitate any networking capabilities.
Full
: Specifies that the task mandates unrestricted, raw IP networking without any imposed filters.
HTTP
: This mode constrains the task to only require HTTP networking with specific domains. In this model:
The job specifier puts forward a job, stipulating the domain(s) it intends to communicate with.
The compute provider assesses the inherent risk of the job based on these domains and bids accordingly.
At runtime, the network traffic remains strictly confined to the designated domain(s).
A typical command for this might resemble: bacalhau docker run —network=http —domain=crates.io —domain=github.com -i ipfs://Qmy1234myd4t4,dst=/code rust/compile
The primary risks for the compute provider center around possible violations of its terms, its hosting provider's terms, or even prevailing laws in its jurisdiction. This encompasses issues such as unauthorized access or distribution of illicit content and potential cyber-attacks.
Conversely, the job specifier's primary risk involves operating in a paid environment. External entities might seek to exploit this environment, for instance, through a compromised package download that initiates a crypto mining operation, depleting the allocated, prepaid job time. By limiting traffic strictly to the pre-specified domains, the potential for such cyber threats diminishes considerably.
While a compute provider might impose its limits through other means, having domains declared upfront allows it to selectively bid on jobs that it can execute without issues, improving the user experience for job specifiers.
Domains (string[]: <optional>)
: A list of domain strings, relevant primarily when the Type
is set to HTTP. It dictates the specific domains the task can communicate with over HTTP.
Understanding and utilizing these configurations aptly can ensure that tasks are executed in an environment that aligns with their networking requirements, bolstering efficiency and security.
The Bacalhau Agent APIs provide a convenient means to retrieve information about the Bacalhau node you are communicating with, whether it serves as the orchestrator or functions as a compute node. These APIs offer valuable insights into the node's health, capabilities, and deployed Bacalhau version.
Endpoint: GET /api/v1/agent/alive
This API can be used to determine if the agent is operational and responding as expected.
Response:
Endpoint: GET /api/v1/agent/version
This API provides details about the Bacalhau version, including major and minor version numbers, Git version, Git commit, build date, and platform information.
Response:
Endpoint: GET /api/v1/agent/node
This API provides detailed information about the node, including its peer ID and network addresses, node type (e.g., Compute), labels, compute node capabilities, and the deployed Bacalhau version.
Response:
The Resources
provides a structured way to detail the computational resources a Task
requires. By specifying these requirements, you ensure that the task is scheduled on a node with adequate resources, optimizing performance and avoiding potential issues linked to resource constraints.
Resources
Parameters:CPU (string: <optional>)
: Defines the CPU resources required for the task. Units can be specified in cores (e.g., 2
for 2 CPU cores) or in milliCPU units (e.g., 250m
or 0.25
for 250 milliCPU units). For instance, if you have half a CPU core, you can represent it as 500m
or 0.5
.
Memory (string: <optional>)
: Highlights the amount of RAM needed for the task. You can specify the memory in various units such as:
Kb
for Kilobytes
Mb
for Megabytes
Gb
for Gigabytes
Tb
for Terabytes
Disk (string: <optional>)
: States the disk storage space needed for the task. Similarly, the disk space can be expressed in units like Gb
for Gigabytes, Mb
for Megabytes, and so on. As an example, 10Gb
indicates 10 Gigabytes of storage space.
GPU (string: <optional>)
: Denotes the number of GPU units required. For example, 2
signifies the requirement of 2 GPU units. This is crucial for tasks involving heavy computational processes, machine learning models, or tasks that leverage GPU acceleration.
The Timeouts
object provides a mechanism to impose timing constraints on specific task operations, particularly execution. By setting these timeouts, users can ensure tasks don't run indefinitely and align them with intended durations.
Timeouts
Parameters:ExecutionTimeout (int: <optional>)
: Defines the maximum duration (in seconds) that a task is permitted to run. A value of zero indicates that there's no set timeout. This could be particularly useful for tasks that function as daemons and are designed to run indefinitely.
Utilizing the Timeouts
judiciously helps in managing resource utilization and ensures tasks adhere to expected timelines, thereby enhancing the efficiency and predictability of job executions.
Docker Engine is one of the execution engines supported in Bacalhau. It allows users to run tasks inside Docker containers, offering an isolated and consistent environment for execution. Below are the parameters to configure the Docker Engine.
Docker
Engine ParametersImage (string: <required>)
: Specifies the Docker image to use for task execution. It should be an image that can be pulled by Docker.
Entrypoint (string[]: <optional>)
: Allows overriding the default entrypoint set in the Docker image. Each string in the array represents a segment of the entrypoint command.
Parameters (string[]: <optional>)
: Additional command-line arguments to be included in the container’s startup command, appended after the entrypoint.
EnvironmentVariables (string[]: <optional>)
: Sets environment variables within the Docker container during task execution. Each string should be formatted as KEY=value
.
WorkingDirectory (string: <optional>)
: Sets the path inside the container where the task executes. If not specified, it defaults to the working directory defined in the Docker image.
Here’s an example of configuring the Docker Engine within a job or task using YAML:
In this example, the task will be executed inside an Ubuntu 20.04 Docker container. The entrypoint is overridden to execute a bash shell that runs an echo command. An environment variable MY_ENV_VAR is set with the value myvalue, and the working directory inside the container is set to /app.
A ResultPath
denotes a specific location within a Task
that contains meaningful output or results. By specifying a ResultPath
, you can pinpoint which files or directories are essential and should be retained or published after the task's execution.
ResultPath
Parameters:Name: A descriptive label or identifier for the result, allowing for easier referencing and understanding of the output's nature or significance.
Path: Specifies the exact location, either a file or a directory, within the task's environment where the result or output is stored. This ensures that after the task completes, the critical data at this path can be accessed, retained, or published as necessary.
A Task
signifies a distinct unit of work within the broader context of a Job
. It defines the specifics of how the task should be executed, where the results should be published, what environment variables are needed, among other configurations
Task
ParametersName (string : <required>)
: A unique identifier representing the name of the task.
Engine (
: required)
: Configures the execution engine for the task, such as or .
Publisher (
: optional)
: Specifies where the results of the task should be published, such as and publishers. Only applicable for tasks of type batch
and ops
.
Env (map[string]string : optional)
: A set of environment variables for the driver.
Meta (
: optional)
: Allows association of arbitrary metadata with this task.
InputSources (
[] : optional)
: Lists remote artifacts that should be downloaded before task execution and mounted within the task, such as from or .
ResultPaths (
[] : optional)
: Indicates volumes within the task that should be included in the published result. Only applicable for tasks of type batch
and ops
.
Resources (
: optional)
: Details the resources that this task requires.
Network (
: optional)
: Configurations related to the networking aspects of the task.
Timeouts (
: optional)
: Configurations concerning any timeouts associated with the task.
Bacalhau's Local Publisher provides a useful option for storing task results on the compute node, allowing for ease of access and retrieval for testing or trying our Bacalhau.
The Local Publisher should not be used for Production use as it is not a reliable storage option. For production use, we recommend using a more reliable option such as an S3-compatible storage service.
The local publisher requires no specific parameters to be defined in the publisher specification. The user only needs to indicate the publisher type as "local", and Bacalhau handles the rest. Here is an example of how to set up a Local Publisher in a job specification.
Once the job is executed, the results are published to the local compute node, and stored as compressed tar file, which can be accessed and retrieved over HTTP from the command line using the get
command. TAhis will download and extract the contents for the user from the remove compute node.
URL (string)
: This is the HTTP URL to the results of the computation, which is hosted on the compute node where it ran. Here's a sample of how the published result might appear:
In this example, the task results will be stored on the compute node, and can be referenced and retrieved using the specified URL.
By default the compute node will attempt to use a public address for the HTTP server delivering task output, but there is no guarantee that the compute node is accessible on that address. If the compute node is behind a NAT or firewall, the user may need to manually specify the address to use for the HTTP server in the config.yaml
file.
There is no lifecycle management for the content stored on the compute node. The user is responsible for managing the content and ensuring that it is removed when no longer needed before the compute node runs out of disk space.
If the address/port of the compute node changes, then previously stored content will no longer be accessible. The user will need to manually update the address in the config.yaml
file and re-publish the content to make it accessible again.
The Local input source allows Bacalhau jobs to access files and directories that are already present on the compute node. This is especially useful for utilizing locally stored datasets, configuration files, logs, or other necessary resources without the need to fetch them from a remote source, ensuring faster job initialization and execution.
Here are the parameters that you can define for a Local input source:
SourcePath (string: <required>)
: The absolute path on the compute node where the Local or file is located. Bacalhau will access this path to read data, and if permitted, write data as well.
ReadWrite (bool: false)
: A boolean flag that, when set to true, gives Bacalhau both read and write access to the specified Local or file. If set to false, Bacalhau will have read-only access.
For security reasons, direct access to local paths must be explicitly allowed when running the Bacalhau compute node. This is achieved using the Compute.AllowListedLocalPaths
configuration key followed by a comma-separated list of the paths, or path patterns, that should be accessible. Each path can be suffixed with permissions as well:
:rw
- Read-Write access.
:ro
- Read-Only access (default if no suffix is provided).
Check out the default settings on your server, as this may be set to :ro
and may lead to an error, when a different access is required.
For instance:
Below is an example of how to define a Local input source in YAML format.
In this example, Bacalhau is configured to access the Local "/etc/config" on the compute node. The contents of this directory are made available at the "/config" path within the task's environment, with read and write access. Adjusting the ReadWrite
flag to false would enable read-only access, preventing modifications to the local data from within the Bacalhau task.
When using the Bacalhau CLI to define the local input source, you can employ the following imperative approach. Below are example commands demonstrating how to define the local input source with various configurations:
Mount readonly file to /config
:
Mount writable file to default /input
:
The different job types available in Bacalhau
Bacalhau has recently introduced different job types in v1.1, providing more control and flexibility over the orchestration and scheduling of those jobs - depending on their type.
Despite the differences in job types, all jobs benefit from core functionalities provided by Bacalhau, including:
Node selection - the appropriate nodes are selected based on several criteria, including resource availability, priority and feedback from the nodes.
Job monitoring - jobs are monitored to ensure they complete, and that they stay in a healthy state.
Retries - within limits, Bacalhau will retry certain jobs a set number of times should it fail to complete successfully when requested.
Batch jobs are executed on demand, running on a specified number of Bacalhau nodes. These jobs either run until completion or until they reach a timeout. They are designed to carry out a single, discrete task before finishing. This is the only job type.
Ideal for intermittent yet intensive data dives, for instance performing computation over large datasets before publishing the response. This approach eliminates the continuous processing overhead, focusing on specific, in-depth investigations and computation.
Similar to batch jobs, ops jobs have a broader reach. They are executed on all nodes that align with the job specification, but otherwise behave like batch jobs.
Ops jobs are perfect for urgent investigations, granting direct access to logs on host machines, where previously you may have had to wait for the logs to arrive at a central location before being able to query them. They can also be used for delivering configuration files for other systems should you wish to deploy an update to many machines at once.
Daemon jobs run continuously on all nodes that meet the criteria given in the job specification. Should any new compute nodes join the cluster after the job was started, and should they meet the criteria, the job will be scheduled to run on that node too.
A good application of daemon jobs is to handle continuously generated data on every compute node. This might be from edge devices like sensors, or cameras, or from logs where they are generated. The data can then be aggregated and compressed them before sending it onwards. For logs, the aggregated data can be relayed at regular intervals to platforms like Kafka or Kinesis, or directly to other logging services with edge devices potentially delivering results via MQTT.
Service jobs run continuously on a specified number of nodes that meet the criteria given in the job specification. Bacalhau's orchestrator selects the optimal nodes to run the job, and continuously monitors its health, performance. If required, it will reschedule on other nodes.
This job type is good for long-running consumers such as streaming or queuing services, or real-time event listeners.
The IPFS Publisher in Bacalhau amplifies the versatility of task result storage by integrating with the . IPFS is a protocol and network designed to create a peer-to-peer method of storing and sharing hypermedia in a distributed file system. Bacalhau's seamless integration with IPFS ensures that users have a decentralized option for publishing their task results, enhancing accessibility and resilience while reducing dependence on a single point of failure.
IPFS
Publisher ParametersFor the IPFS publisher, no specific parameters need to be defined in the publisher specification. The user only needs to indicate the publisher type as IPFS, and Bacalhau handles the rest. Here is an example of how to set up an IPFS Publisher in a job specification.
Once the job is executed, the results are published to IPFS, and a unique CID (Content Identifier) is generated for each file or piece of data. This CID acts as an address to the file in the IPFS network and can be used to access the file globally.
CID (string)
: This is the unique content identifier generated by IPFS, which can be used to access the published content from anywhere in the world. Every data piece stored on IPFS has its unique CID. Here's a sample of how the published result might appear:
In this example, the task results will be stored in IPFS, and can be referenced and retrieved using the specified CID. This is indicative of Bacalhau's commitment to offering flexible, reliable, and decentralized options for result storage, catering to a diverse set of user needs and preferences.
The WASM Engine in Bacalhau allows tasks to be executed in a WebAssembly environment, offering compatibility and speed. This engine supports WASM and WASI (WebAssembly System Interface) jobs, making it highly adaptable for various use cases. Below are the parameters for configuring the WASM Engine.
WASM
Engine ParametersEntryModule (
: required)
: Specifies the WASM module that contains the start function or the main execution code of the task. The InputSource should point to the location of the WASM binary.
Entrypoint (string: <optional>)
: The name of the function within the EntryModule to execute. For WASI jobs, this should typically be _start
. The entrypoint function should have zero parameters and zero results.
Parameters (string[]: <optional>)
: An array of strings containing arguments that will be supplied to the program as ARGV. This allows parameterized execution of the WASM task.
EnvironmentVariables (map[string]string: <optional>)
: A mapping of environment variable keys to their values, made available within the executing WASM environment.
ImportModules (
[] : optional)
: An array of InputSources pointing to additional WASM modules. The exports from these modules will be available as imports to the EntryModule, enabling modular and reusable WASM code.
Here’s a sample configuration of the WASM Engine within a task, expressed in YAML:
In this example, the task is configured to run in a WASM environment. The EntryModule is fetched from an S3 bucket, the entrypoint is _start
, and parameters and environment variables are passed into the WASM environment. Additionally, an ImportModule is loaded from a local directory, making its exports available to the EntryModule.
The IPFS Input Source enables users to easily integrate data hosted on the into Bacalhau jobs. By specifying the Content Identifier (CID) of the desired IPFS file or directory, users can have the content fetched and made available in the task's execution environment, ensuring efficient and decentralized data access.
Here are the parameters that you can define for an IPFS input source:
CID (string: <required>)
: The Content Identifier that uniquely pinpoints the file or directory on the IPFS network. Bacalhau retrieves the content associated with this CID for use in the task.
Below is an example of how to define an IPFS input source in YAML format.
In this configuration, the data associated with the specified CID is fetched from the IPFS network and made available in the task's environment at the "/data" path.
Utilizing IPFS as an input source in Bacalhau via the CLI is straightforward. Below are example commands that demonstrate how to define the IPFS input source:
Mount an IPFS CID to the default /inputs
directory:
Mount an IPFS CID to a custom /data
directory:
These commands provide a seamless mechanism to fetch and mount data from IPFS directly into your task's execution environment using the Bacalhau CLI.
Bacalhau's S3 Publisher provides users with a secure and efficient method to publish task results to any S3-compatible storage service. This publisher supports not just AWS S3, but other S3-compatible services offered by cloud providers like Google Cloud Storage and Azure Blob Storage, as well as open-source options like MinIO. The integration is designed to be highly flexible, ensuring users can choose the storage option that aligns with their needs, privacy preferences, and operational requirements.
Bucket (string: <required>)
: The name of the S3 bucket where the task results will be stored.
Key (string: <required>)
: The object key within the specified bucket where the task results will be stored.
Endpoint (string: <optional>)
: The endpoint URL of the S3 service (useful for S3-compatible services).
Region (string: <optional>)
: The region where the S3 bucket is located.
Results published to S3 are stored as objects that can also be used as inputs to other Bacalhau jobs by using . The published result specification includes the following parameters:
Bucket: Confirms the name of the bucket containing the stored results.
Key: Identifies the unique object key within the specified bucket.
Region: Notes the AWS region of the bucket.
Endpoint: Records the endpoint URL for S3-compatible storage services.
VersionID: The version ID of the stored object, enabling versioning support for retrieving specific versions of stored data.
ChecksumSHA256: The SHA-256 checksum of the stored object, providing a method to verify data integrity.
With the S3 Publisher in Bacalhau, you have the flexibility to use dynamic naming for the objects you publish to S3. This allows you to incorporate specific job and execution details into the object key, making it easier to trace, manage, and organize your published artifacts.
Bacalhau supports the following dynamic placeholders that will be replaced with their actual values during the publishing process:
{executionID}
: Replaced with the specific execution ID.
{jobID}
: Replaced with the ID of the job.
{nodeID}
: Replaced with the ID of the node where the execution took place
{date}
: Replaced with the current date in the format YYYYMMDD
.
{time}
: Replaced with the current time in the format HHMMSS
.
Additionally, if you are publishing an archive and the object key does not end with .tar.gz
, it will be automatically appended. Conversely, if you're not archiving and the key doesn't end with a /
, a trailing slash will be added.
Example
Imagine you've specified the following object key pattern for publishing:
Given a job with ID abc123
, executed on 2023-09-26
at 14:05:30
, the published object key would be:
This dynamic naming feature offers a powerful way to create organized, intuitive naming conventions for your Bacalhau published objects in S3.
Here’s an example YAML configuration that outlines the process of using the S3 Publisher with Bacalhau:
In this configuration, task results will be published to the specified S3 bucket and object key. If you’re using an S3-compatible service, simply update the Endpoint
parameter with the appropriate URL.
The results will be compressed into a single object, and the published result specification will look like:
The Bacalhau command-line interface (CLI) provides an imperative approach to specify the S3 Publisher. Below are a few examples showcasing how to define an S3 publisher using CLI commands:
Basic Docker job writing to S3 with default configurations:
This command writes to the S3 bucket using default endpoint and region settings.
Docker job writing to S3 with a specific endpoint and region:
This command specifies a unique endpoint and region for the S3 bucket.
Using naming placeholders:
Dynamic naming placeholders like {date}
and {jobID}
allow for organized naming structures, automatically replacing these placeholders with appropriate values upon execution.
Remember to replace the placeholders like bucket
, key
, and other parameters with your specific values. These CLI commands offer a quick and customizable way to submit jobs and specify how the results should be published to S3.
To support this storage provider, no extra dependencies are necessary. However, valid AWS credentials are essential to sign the requests. The storage provider employs the default credentials chain to retrieve credentials, primarily sourcing them from:
Environment variables: AWS credentials can be specified using AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
environment variables.
Credentials file: The credentials file typically located at ~/.aws/credentials
can also be used to fetch the necessary AWS credentials.
IAM Roles for Amazon EC2 Instances: If you're running your tasks within an Amazon EC2 instance, IAM roles can be utilized to provide the necessary permissions and credentials.
Compute nodes must run with the following policies to publish to S3:
PutObject Permissions: The s3:PutObject
permission is necessary to publish objects to the specified S3 bucket.
Resource: The Resource
field in the policy specifies the Amazon Resource Name (ARN) of the S3 bucket. The /*
suffix is necessary to allow publishing with any prefix within the bucket or can be replaced with a prefix to limit the scope of the policy. You can also specify multiple resources in the policy to allow publishing to multiple buckets, or *
to allow publishing to all buckets in the account.
To enable downloading published results using bacalhau job get <job_id>
command, the requester node must run with the following policies:
GetObject Permissions: The s3:GetObject
permission is necessary for the requester node to provide a pre-signed URL to download the published results by the client.
For a more detailed overview on AWS credential management and other ways to provide these credentials, please refer to the AWS official documentation on .
For more information on IAM policies specific to Amazon S3 buckets and users, please refer to the .
The S3 Input Source provides a seamless way to utilize data stored in S3 or any S3-compatible storage service as input for Bacalhau jobs. Users can specify files or entire prefixes stored in S3 buckets to be fetched and mounted directly into the task's execution environment. This capability ensures that your tasks have immediate access to the necessary data.
Here are the parameters that you can define for an S3 input source:
Bucket (string: <required>)
: The name of the S3 bucket where the data is stored.
Key(string: <optional>)
: The object key or prefix within the bucket. Supports trailing wildcard for fetching multiple objects with matching prefixes.
Filter(string: <optional>)
: A regex pattern to filter the objects to be fetched. If a Key is also provided as a prefix, the filter pattern will be applied to object keys after the prefix.
Region(string: <optional>)
: The AWS region where the S3 bucket is hosted.
Endpoint(string: <optional>)
: The endpoint URL of the S3 or S3-compatible service.
VersionID(string: <optional>)
: The specific version of the object if versioning is enabled on the bucket. Only applicable when fetching a single object, and not a prefix or a pattern of objects.
ChecksumSHA256(string: <optional>)
: The SHA-256 checksum of the object to ensure data integrity. Only applicable when fetching a single object, and not a prefix or a pattern of objects.
Single Object: If the key points to a single object, that object is fetched and made available to the task. e.g. s3://myBucket/dir/file-001.txt
Prefix Matching: If the key ends with a slash (/), it's interpreted as a prefix, and all objects with keys that start with that prefix are fetched, mimicking the behavior of fetching all objects in a "directory". e.g. s3://myBucket/dir/
Wildcard: Supports a trailing wildcard (*
). All objects with keys matching the prefix are fetched, facilitating batch processing or analysis of multiple files. e.g. s3://myBucket/dir/log-2023-09-*
When using the Bacalhau YAML configuration to define the S3 input source, you can employ the following declarative approach.
Below is an example of how to define an S3 input source in YAML format.
When using the Bacalhau CLI to define the S3 input source, you can employ the following imperative approach. Below are example commands demonstrating how to define the S3 input source with various configurations:
Mount an S3 object to a specific path:
Mount an S3 object with a specific endpoint and region:
Mount an S3 object using long flag names:
With these commands, you can seamlessly fetch and mount data from S3 into your task's execution environment directly through the CLI.
To support this storage provider, no extra dependencies are necessary. However, valid AWS credentials are essential to sign the requests. The storage provider employs the default credentials chain to retrieve credentials, primarily sourcing them from:
Environment variables: AWS credentials can be specified using AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
environment variables.
Credentials file: The credentials file typically located at ~/.aws/credentials
can also be used to fetch the necessary AWS credentials.
IAM Roles for Amazon EC2 Instances: If you're running your tasks within an Amazon EC2 instance, IAM roles can be utilized to provide the necessary permissions and credentials.
For a more detailed overview on AWS credential management and other ways to provide these credentials, please refer to the AWS official documentation on standardized credentials.
Compute nodes must run with the following policies to support S3 input source:
ListBucket Permission: The s3:ListBucket
permission is necessary to list the objects within the specified S3 bucket, allowing prefixes and wildcard expressions as the S3 Key for fetching.
GetObject and GetObjectVersion Permissions: The s3:GetObject
and s3:GetObjectVersion
permissions enable the fetching of object data and its versions, respectively.
Resource: The Resource
field in the policy specifies the Amazon Resource Name (ARN) of the S3 bucket. The /*
suffix is necessary to allow fetching of all objects within the bucket or can be replaced with a prefix to limit the scope of the policy. You can also specify multiple resources in the policy to allow fetching from multiple buckets, or *
to allow fetching from all buckets in the account.
For more information on IAM policies specific to Amazon S3 buckets and users, please refer to the AWS documentation on Using IAM Policies with Amazon S3.
This feature isn't limited to AWS S3 - it supports all S3-compatible storage services. It means you can pull data from the likes of Google Cloud Storage and open-source solutions like MinIO, giving you the flexibility to utilize a diverse range of data sources.
To seamlessly integrate Google Cloud Storage with Bacalhau, follow these steps:
Obtain HMAC Keys: To access Google Cloud Storage, you'll need HMAC (Hash-based Message Authentication Code) keys. Refer to the Google Cloud documentation for detailed instructions on creating a service account and generating HMAC keys.
Provide HMAC Keys to Bacalhau: You can provide the HMAC keys to Bacalhau using the same options as AWS credentials, as documented in the Credential Requirements section.
Configure the S3 Input Source: In your S3 input source configuration, set the endpoint for Google Cloud Storage to https://storage.googleapis.com
, as shown in the example below:
The URL Input Source provides a straightforward method for Bacalhau jobs to access and incorporate data available over HTTP/HTTPS. By specifying a URL, users can ensure the required data, whether a single file or a web page content, is retrieved and prepared in the task's execution environment, enabling direct and efficient data utilization.
Here are the parameters that you can define for a URL input source:
URL (string: <required>)
: The HTTP/HTTPS URL pointing directly to the file or web content you want to retrieve. The content accessible at this URL will be fetched and made available in the task’s environment.
Below is an example of how to define a URL input source in YAML format.
In this setup, the content available at the specified URL is downloaded and stored at the "/data" path within the task's environment. This mechanism ensures that tasks can directly access a broad range of web-based resources, augmenting the adaptability and utility of Bacalhau jobs.
When using the Bacalhau CLI to define the URL input source, you can employ the following imperative approach. Below are example commands demonstrating how to define the URL input source with various configurations:
Fetch data from an HTTP endpoint and mount it: This command demonstrates fetching data from a specific HTTP URL and mounting it to a designated path within the task's environment.
Fetch data from an HTTPS endpoint and mount it: Similarly, you can fetch data from secure HTTPS URLs. This example fetches a file from a secure URL and mounts it.
SpecConfig
provides a unified structure to specify configurations for various components in Bacalhau, including engines, publishers, and input sources. Its flexible design allows seamless integration with multiple systems like Docker, WebAssembly (Wasm), AWS S3, and local directories, among others.
SpecConfig
ParametersType (string : <required>)
: Specifies the type of the configuration. Examples include docker
and wasm
for execution engines, S3
for input sources and publishers, etc.
Params (map[string]any : <optional>)
: A set of key-value pairs that provide the specific configurations for the chosen type. The keys and values are flexible and depend on the Type
. For instance, parameters for a Docker engine might include image name and version, while an S3 publisher would require configurations like the bucket name and AWS region. If not provided, it defaults to nil
.
Here are a few hypothetical examples to demonstrate how you might define SpecConfig
for different components:
Copy
Full Docker spec can be found here.
Copy
Full S3 Publisher can be found here.
Copy
Full local source can be found here.
Remember, the exact keys and values in the Params
map will vary depending on the specific requirements of the component being configured. Always refer to the individual component's documentation to understand the available parameters.
State
Structure SpecificationWithin Bacalhau, the State
structure is designed to represent the status or state of an object (like a Job
), coupled with a human-readable message for added context. Below is a breakdown of the structure:
State
ParametersStateType (T : <required>)
: Represents the current state of the object. This is a generic parameter that will take on a specific value from a set of defined state types for the object in question. For jobs, this will be one of the JobStateType
values.
Message (string : <optional>)
: A human-readable message giving more context about the current state. Particularly useful for states like Failed
to provide insight into the nature of any error.
When State
is used for a job, the StateType
can be one of the following:
Pending
: This indicates that the job is submitted but is not yet scheduled for execution.
Running
: The job is scheduled and is currently undergoing execution.
Completed
: This state signifies that a job has successfully executed its task. Only applicable for batch jobs.
Failed
: A state indicating that the job encountered errors and couldn't successfully complete.
JobStateTypeStopped
: The job has been intentionally halted by the user before its natural completion.
The inclusion of the Message
field can offer detailed insights, especially in states like Failed
, aiding in error comprehension and debugging.