Skip to content

Releases: bacalhau-project/bacalhau

v1.5.0-alpha3

17 Sep 06:57
ac24db9
Compare
Choose a tag to compare
v1.5.0-alpha3 Pre-release
Pre-release

What's Changed

Full Changelog: v1.4.0...v1.5.0-alpha3

v1.4.0

30 Jun 10:19
081eabf
Compare
Choose a tag to compare

Announcing Bacalhau 1.4.0

We’re excited to announce the release of Bacalhau 1.4.0, a significant update that introduces powerful new features and enhancements. Building on the momentum from our previous releases this year (1.2.0, 1.3.0, 1.3.1, and 1.3.2), Bacalhau 1.4 strengthens our platform’s performance, scalability, and user experience, solidifying its position as a leading platform for building and running distributed compute networks.

In this release, we focused on three major efforts, with particular emphasis on those deploying Bacalhau at scale:

Performance and Scalability Enhancements

  • Extended Job Queuing: Bacalhau 1.4.0 introduces a more robust queuing system, improving job scheduling and execution efficiency, especially in high-demand or globally distributed networks. By intelligently managing job queues, Bacalhau ensures smoother operations and increased throughput, leading to higher success rates for your distributed compute tasks.

  • Migration to NATS, Deprecation of libp2p and Embedded IPFS Node: We’ve fully transitioned to NATS.io as Bacalhau’s communication backbone, moving away from libp2p and the embedded IPFS node. This change streamlines communication and reduces overhead, marking a significant step towards a more efficient and scalable network. IPFS integration remains available with external nodes for those who need it. 

Improved User Experience

  • Updated CLI and HTTP API: Bacalhau 1.4.0 introduces a revamped command-line interface (CLI) and HTTP API. These updates align the CLI commands with the new API structure and enhance overall usability. While most changes are seamless for existing users, some command adjustments have been made (e.g., bacalhau create becomes bacalhau job run). Our updated documentation will guide you through the transition smoothly. 

  • Job Spec Updates: We've introduced an updated Job Specification format while deprecating some features of the previous format. This change requires users to update their job specs but brings improved clarity and consistency.

  • Enhanced Error Reporting: Bacalhau 1.4.0 improves error reporting, making it easier to diagnose and troubleshoot issues. This enhancement contributes to a more stable and reliable experience, helping users quickly resolve any problems that arise. For detailed guidance, please consult our documentation on the new Job Spec requirements.

  • Introduction of Node Manager:  In Bacalhau 1.4.0, we’re introducing the Node Manager. This feature simplifies node operations, providing a clear view of all compute nodes and their status. You can approve, deny, or delete nodes as needed, making management straightforward. Heartbeats from nodes keep the Node Manager updated on their connectivity, enhancing overall stability and performance.

Smooth Transition for Existing Users

  • Error Handling and Guidance: We understand that transitioning to a new version can be challenging. To ease this process, we’ve implemented helpful error messages and guidance for those adjusting to the changes in CLI behavior and job specifications. We’ve also created a table to show how some of the Bacalhau API endpoints have been remapped. If you’re not ready to upgrade, you can continue using version 1.3.1 while maintaining your private Bacalhau cluster.

Join Us on the Journey

We’re excited for you to explore the new features and enhancements in Bacalhau 1.4.0. Over the next five days, we’ll dive deeper into each topic in our “5 Days of Bacalhau” blog series. Whether you’re a seasoned Bacalhau user or just getting started, this update will empower you to build and run distributed compute networks more effectively than ever before.

v1.3.2

04 Jun 20:12
03e0d03
Compare
Choose a tag to compare

What's Changed

  • Splitting to Consumer and Producer Client by @udsamani in #4027
  • refactor: define config instance. config is no longer global by @frrist in #3959
  • ops: update prod cluster vars to reflect current state by @frrist in #4034
  • introduce job queueing when no nodes were found by @wdbaruni in #4049
  • filter out nodes with high queue capacity by @wdbaruni in #4051
  • Update canaries to 1.3.1 by @wdbaruni in #4039

Full Changelog: v1.3.1...v1.3.2

v1.3.2-rc2

30 May 19:15
Compare
Choose a tag to compare
v1.3.2-rc2 Pre-release
Pre-release

What's Changed

Full Changelog: v1.3.1...v1.3.2-rc2

v1.3.2-rc1

30 May 18:07
Compare
Choose a tag to compare
v1.3.2-rc1 Pre-release
Pre-release

What's Changed

Full Changelog: v1.3.1...v1.3.2-rc1

v1.3.1

23 May 23:11
6917674
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v1.3.0...v1.3.1

v1.3.1-rc2

23 May 19:45
6917674
Compare
Choose a tag to compare
v1.3.1-rc2 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: v1.3.0...v1.3.1-rc2

v1.3.1-rc1

22 May 19:24
fa27190
Compare
Choose a tag to compare
v1.3.1-rc1 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: v1.3.0...v1.3.1-rc1

v1.3.0

25 Mar 15:21
5428f7f
Compare
Choose a tag to compare

We are thrilled to announce the release of Bacalhau v1.3.0, a significant milestone in our quest for helping organizations of all sizes deal with the world of distributed compute. Packed with exciting new features like user access control, local results publishing, and TLS support, this release is built to address the needs of even the largest organizations without the complexity of traditional distributed platforms! 🚀

Without further ado, let’s dive in!

New Features

User access control

Bacalhau v1.3.0 now supports authentication and authorization of individual users with a flexible and customizable auth system that remains simple for single-node clusters but scales up well to wide enterprise deployments.

Bacalhau auth integrates well with whatever auth systems users already have. Bacalhau can use private keys, shared secrets, usernames, and passwords and 2FA. Additionally, Bacalhau offers OAuth2/OIDC for authentication and can apply access control to single users, groups, teams and can use RBAC or ABAC mechanisms as desired.

The default behaviour is unchanged. Users will be authenticated based on their private key and authorized to submit and control their own jobs and read-only information about the cluster will be available with authentication.

To start using user authentication, check out the auth docs and install a custom policy to control user access and their permissions.

Publishing and serving results on local disks

In Bacalhau v1.3.0 we are introducing a new publisher type that lets users publish to the local disk of the compute node. This will streamline the process of testing the publisher functionality without the need for a remote storage service. This is especially handy for those who are just getting started with Bacalhau.

The local publisher is composed of two parts: the publisher that compresses and moves job outputs to a specified location, and an HTTP server that delivers the content back to the user.

By default, the HTTP server listens on port 6001, but this can be modified using the --local-publisher-port flag. The server will deliver content from the directory specified by the local-publisher-directory flag, or, if not set, from a subdirectory of the configured Bacalhau storage directory. The --local-publisher-address flag can be used to set the address that the HTTP server listens on. Default values for this vary by environment (e.g., localhost for test and development environments, public for production environments), but users can set these values in the config if the defaults are not suitable.

We should stress that managing the storage is still the administrator’s responsibility. Because local storage necessarily means storing on a single node, thinking through clean up, persistence, etc. are things you should think through before moving into production!

NATS-based networking

In the Bacalhau v1.3.0 release, we are introducing a new transport layer to improve inter-node connectivity. This new layer utilizes NATS, a robust messaging system, instead of the existing libp2p transport.

With the introduction of NATS, we are simplifying the network requirements for Compute nodes. Now, only Orchestrator nodes (also known as Requester nodes) need to be publicly reachable. As a result, Compute nodes only need to know the address of a single Orchestrator node, and they can learn about and connect to other Orchestrators at runtime. This change not only simplifies the setup process but also enhances resilience as it allows Compute nodes to failover and reconnect to other Orchestrators when necessary. This change only affects inter-node communication, and the Bacalhau HTTP API is unchanged.

We acknowledge that adapting to new technologies takes time. In recognition of this, libp2p will continue to be supported as an alternative during this transition period. This ensures that you have the flexibility to migrate at your own pace. Users who wish to continue using libp2p need to specify the Node.Network.Type config option or --network flag as libp2p explicitly when running their network.

Persistent memory of connected nodes

The Bacalhau v1.3.0 release introduces a significant upgrade ensuring the persistence of node information across requester node restarts. This addresses a shortcoming of the previous in-memory store, which would lose all knowledge of compute nodes upon a restart. The new persistent store is a major advancement towards maintaining more accurate node information and tracking compute nodes that may be temporarily inaccessible to the cluster.

The new persistent store is used automatically when NATS-based networking is used.

TLS support for Bacalhau CLI

Bacalhau v1.3.0 now supports TLS requests to the requester node for all CLI commands. While the default communication remains HTTP, users can activate TLS calls using the command line flag --tls , setting the Node.ClientAPI.ClientTLS.UseTLS config option to true or by exporting the BACALHAU_API_TLS=1 environment variable.

For self-signed certificates, users can either accept insecure requests or provide a CA certificate file. The Node.ClientAPI.ClientTLS.CACert config option, BACALHAU_API_CACERT environment variable and --cacert flag can be used to verify the certificate with a provided CA certificate file. Alternatively, the Node.ClientAPI.ClientTLS.Insecure config option, --insecure flag or BACALHAU_API_INSECURE environment variable can be used to make API requests without certificate verification.

Customizable node names

In the Bacalhau v1.3.0 release, we've introduced a new feature that allows users to set their own nodeID. This addition gives users the flexibility to tailor their node names according to their preferences and needs.

Users have the option to manually set the node name, or they can opt for automatic generation using various providers. These providers include puuid (which is the default option), uuid, hostname, aws, and gcp.

The puuid option generates a node name using the n-{uuid} pattern, such as n-f1bab231-68ad-4c72-bab6-580cd49bf521. The uuid option generates a uuid as a node name. The hostname option uses the hostname as the node id, replacing any . with - to ensure compatibility with NATS. The aws option uses the EC2 instance name if the node is deployed on AWS, and the gcp option uses the VM's id if the node is deployed on GCP.

It's important to note that these providers will only be called into action if no existing node name is found in config.yaml, the CLI --name flag, or environment variables. Once a node name is generated, it will be persisted in config.yaml, ensuring that the node names are consistent across sessions.

To set the node name manually:

bacalhau serve --name my-custom-name

To use a puuid as the node name (which is the default):

bacalhau serve

To use the hostname as the node name:

bacalhau serve --name-provider hostname

This new feature is aimed at enhancing user customization and control, making Bacalhau even more user-friendly and adaptable to different user needs.

Improved telemetry and metrics

Bacalhau Telemetry Suite

In this update we have introduced a docker-compose based telemetry suite complete with open-telemetry, Prometheus, Grafana, and Jaeger containers for collecting and inspecting telemetry data emitted from bacalhau nodes. For details on running the suite see the respective README.md

Improved Visibility via New Metrics

In this update we have added new metrics to improve the observability of bacalhau nodes. These metrics include:

  • job_submitted: Number of jobs submitted to the Bacalhau node.
  • job_publish_duration_milliseconds: Duration of publishing a job on the compute node in milliseconds.
  • job_storage_upload_duration_milliseconds: Duration of uploading job storage input on the compute node in milliseconds.
  • job_storage_prepare_duration_milliseconds: Duration of preparing job storage input on the compute node in milliseconds.
  • job_storage_cleanup_duration_milliseconds: Duration of job storage input cleanup on the compute node in milliseconds.
  • job_duration_milliseconds: Duration of a job on the compute node in milliseconds.
  • docker_active_executions: Number of active docker executions on the compute node.
  • wasm_active_executions: Number of active WASM executions on the compute node.
  • bacalhau_node_info: A static metric with labels describing the bacalhau node.
    • node_id: ID of bacalhau node emitting metric
    • node_network_transport: bacalhau node network transport type (libp2p or NATs)
    • node_is_compute: true if the node is accepting compute jobs
    • node_is_requester: true if the node is serving as a requester node
    • node_engines: list of engines the node supports.
    • node_publishers: list of publishers the node supports.
    • node_storages: list of storages the node supports

Improved Out of Memory handling for Docker jobs

The Bacalhau CLI will now explain when Docker jobs run out of memory and include links to the Bacalhau documentation showing how to increase the memory limit for a job.

Improved configuration for IPFS

In this update, we have allowed for the embedded IPFS nodes gateway, API, and swarm listening multi-addresses to be configured, providing users with more control and determinism, particularly when configuring firewall rules.

This update also introduces changes when the --ipfs-serve-path flag is set, now preserving the content of the embedded IPFS nodes repo across Bacalhau restarts, maintaining any data the embedded IPFS node stored as well as its identity.

F...

Read more

v1.3.0-rc3

21 Mar 17:15
0948775
Compare
Choose a tag to compare
v1.3.0-rc3 Pre-release
Pre-release

What's Changed

Full Changelog: v1.2.3...v1.3.0-rc3