v0.0.16

This release largely consists of updates to Runhouse infrastructure and build, with the addition of two new runhouse CLI commands (stop and status), basic ASGI support, and some bug fixes.

Note: We’ve removed some dependencies to better support local-only use cases of Runhouse. To use Runhouse with a cluster, please install with pip install “runhouse[sky]”, and to use Runhouse data structures like tables, please install with pip install “runhouse[data]”

Improvements

• Change Module's endpoint from property to function (#367)
• Change ray to only be initialized in runhouse start or HTTPServer() (#369)
• Ray start to connect to existing cluster (#405)

New features

• Introduce Asgi module and support calling route functions directly (#370)
• Add runhouse stop command/function (#392)
• Add deleting env servlet functionality (#417)
• Add runhouse status command (#416)

Build

• Relax hard dependency on sky (#414)
• Localize data dependency imports (#418)

Bug Fixes

• Account for workdir or compute in env factory (#354)
• rh.here working (#338)
• Fix to function's .notebook() functionality (#362)
• Only set rns_address upon save (#434)

BC-Breaking

• Replace num_entries with limit for resource history API (#399)

v0.0.15

Highlights

• Mapper, a built-in Runhouse module for mapping functions over a list of inputs across compute (#327)
• Python3.11 support (#279)

rh.Mapper Module

The Mapper expands Runhouse functions and Module methods to handle mapping, replicating, and load balancing. A Mapper object is constructed simply by passing in a function or module and module method, along with the number of replicas to use, and optionally your own user-specified replicas. It takes the function and creates replicas of it and its envs, and round-robin calls the replicas to run function calls in parallel.

def local_sum(arg1, arg2, arg3):
	return arg1 + arg2 + arg3

remote_fn = rh.function(local_sum).to(my_cluster)
mapper = rh.mapper(remote_fn, num_replicas=2)
mapper.map([1, 2], [1, 4], [2, 3])
# output: [4,9]

Improvements

Better multinode cluster support

• Sync runhouse to all nodes instead of just the head node (#278)
• Start Ray on both head and worker nodes (#305)
• Add back support for cluster IPs (#346)
  Introduce cluster servlet for handling global cluster object store (#308)

Build

• Python3.11 support (#279)
• Update AWS dependencies (#290)

Bug Fixes

• Fix streaming with HTTP/HTTPS/Nginx (#261)

BC-Breaking

• Replace instance_count with num_instances for cluster class (#269)

Docs

• Updated quick start and compute tutorials (#310, #347)

v0.0.14

Highlights

• Secrets Revamp (#135)
  • Facilitate saving, sending, and sharing of Secrets by treating Secrets as a Runhouse resource
• (Alpha) AWS Lambda Functions support (#139, #240, #244)
  • Introduce AWS Lambda support for Runhouse functions

Secrets Revamp

The rh.Secrets class is being deprecated in favor of converting secrets to a Runhouse resource type. As with other resources, the new Secret class supports saving, reloading, and sending secrets across clusters.

There are various builtin secret provider types, for keeping track of compute providers (aws, azure, gcp..), api key based providers (openai, anthropic, …), and ssh key pairs.

# non-provider secret, in-memory
my_secret = rh.secret(name=”my_secret”, values={“key1”: “val1”, “key2”: “val2”})
my_secret.save()
reloaded_secret = rh.secret(“my_secret”)

# provider secret, in-memory or loaded from default location
aws_secret = rh.provider_secret(“aws”)  # loads from ~/.aws/credentials or from env vars
openai_secret = rh.provider_secret(“openai”, values={“api_key”: “my_openai_key”})  # explicitly provided values

There are also various APIs for syncing secrets across your clusters and environments:

aws_secret.to(cluster, env)
cluster.sync_secrets([“aws”, “gcp”], env)

env = rh.env(secrets=[“aws”, “openai”]
fn.to(cluster, env)

Please refer to the API tutorial for a more in-depth walkthrough of using Secrets, or the documentation for specific APIs and a full list of builtin providers.

(Alpha) Lambda Functions (AWS serverless)

Runhouse is extending functions to Amazon Web Services (AWS) Lambda Compute. These functions are deployed directly on AWS serverless compute, with Lambda’s infra and servers handled under the hood, making the Lambda onboarding process more smooth and removing the need to translate code through Lambda-specific APIs.

Note: Lambda Functions are in Alpha and the APIs are subject to change. A more stable release along with examples will be published soon. In the meantime, you can find documentation here.

New Additions

• Add visibility to resource config, and enable public resources (#222)
• API for revoking access to shared secrets (#235)

Bug Fixes

• Proper tunnel caching (#191, #194): tunnels were not previously being cached correctly, and dead connections not accounted for
• Sagemaker cluster launch fix (#206): remove runhouse as a dependency from the launch script, as it has not yet been installed on the cluster
• Fix bug with loading runhouse files/folders through SSH fsspec (#225): custom SSH port was not being set in fsspec filesystem of runhouse files/folders
• Correctly launch multiple node clusters according to num_instances (#229): previously was not properly launching multiple nodes

Deprecations + BC-Breaking

• access_type deprecated and renamed to access_level for resource and sharing (#223, #224, #231)
• rh.Secrets class deprecated in favor of convert Secrets to a resource type ((#135). Some old APIs are removed, and others are deprecated. Please refer to docs and tutorial for the new secrets flow.

Other

• README updates (#187)
• Various docs updates

v0.0.13

Highlights

• AWS Sagemaker Cluster (#105 #115 #166)
  • facilitates easy access to existing or new AWS SageMaker compute
• HTTPS support (Alpha) (#114)
  • adds option for starting up the Runhouse API server on the cluster with HTTPS

Sagemaker Cluster

Runhouse is integrating with Amazon Web Services (AWS) SageMaker to allow rapid onboarding onto SageMaker, usually within minutes, and to remove the need to translate code into SageMaker-specific APIs so it can still be used dynamically with other compute infra.

The SageMaker cluster follows the Runhouse cluster definition and usage, but uses Sagemaker compute under the hood.

If you already use SageMaker with your AWS account, you should already be set to use Runhouse SageMaker support. For full SageMaker setup and dependencies, please refer to the docs.

Example 1: Launch a new SageMaker instance and keep it up indefinitely.

# Note: this will use Role ARN associated with the "sagemaker" profile defined in the local AWS config (e.g. `~/.aws/config`).
import runhouse as rh
c = rh.sagemaker_cluster(name='sm-cluster', profile="sagemaker").save()

Example 2: Running a training job with a provided Estimator

c = rh.sagemaker_cluster(name='sagemaker-cluster',
                          estimator=PyTorch(entry_point='train.py',
                                            role='arn:aws:iam::123456789012:role/MySageMakerRole',
                                            source_dir='/Users/myuser/dev/sagemaker',
                                            framework_version='1.8.1',
                                            py_version='py36',
                                            instance_type='ml.p3.2xlarge'),
                          ).save()

Support HTTPS calls to clusters (Alpha)

Adds an option for starting up the Runhouse API server on the cluster with HTTPS, including optionally creating self-signed certs and proxying through Nginx. This makes it incredibly fast and easy to stand up a microservice with standard bearer token authentication (using a Runhouse token), allowing users to share Runhouse resources with collaborators, teams, customers, etc.

Supports several new server connection types, including tls, ssh. For more information on these types, please refer to docs.

BC Breaking

• The default Runhouse HTTP server port is now 32300 (#124)

Other

• Remove the paramiko dependency for password clusters (#131)
• Support running shell commands in env (#132)
  Example code:

rh.env(
        name="my_env",
        reqs=["torch", "diffusers"],
        setup_cmds=["source ~/.bashrc"]
)

• Support an optional host parameter for the runhouse start and runhouse restart commands, which now defaults to 0.0.0.0 (#110)
  Example code:

runhouse restart --host 0.0.0.0

v0.0.12

Highlights

• In-memory resources, an update to existing remote resource implementations (#78)
  • includes new rh.Module resource, and resulting performance and feature improvements
• Sagemaker Cluster (Alpha) (#89)
  • facilitates easy access to existing or new SageMaker compute

In-memory Resources

As mentioned in the 0.0.11 Release Notes, we've redesigned how we handle remote resources, resulting in performance and feature improvements, as well as support for a new type of resource. Basic notes can be found below, or a more comprehensive technical overview can be found in our 0.0.12 blog post

rh.Module Resource

rh.Module represents a class that can be accessed and used remotely, including all its class methods and variables, and with out-of-the-box support for capabilities like streaming logs/results, async, queuing, etc

• rh.module() factory function for wrapping existing Python classes
• rh.Module class that can be subclasses to write natively Runhouse-compatible classes

In-Python Object Pinning

Storing large objects, such as models, in Python memory can reduce time spent loading objects from disk or sending them over.

• more stable object pinning in Python memory
• intuitive rh.here.get() and rh.here.put() APIs, where rh.here returns the cluster it is called from

Performance Improvements

• Reduced process overhead and latency, by having each underlying Ray Actor live in it's own process rather than launching

Other resulting improvements

• Streaming support
• Increased logging support
• Async support

Sagemaker Cluster (Alpha)

Runhouse is integrating with SageMaker to make the SageMaker onboarding process more smooth, and removing the need to translate code through SageMaker specific estimators or APIs. This will be described in more detail in the 0.0.13 release, or check out the documentation in the meantime.

Build

• Remove s3fs dependency
• Upgrade to SkyPilot 0.0.4, to resolve Colab installation issues

BC Breaking

• .remote() now returns a remote object, rather than a string associated with the object/run. To get the contents of the result, use result.fetch()

v0.0.11

What's New

In-memory Resources (Alpha)

We revamped our underlying code implementation for handling remote code execution, resulting in improvements and added support for:

• True in-Python pinning
• Improved performance and decreased process overhead
• Increased support for streaming and logs
• Remote classes and class method calls (rh.Module resource)

These new features and updates will be explained in more detail in the following (0.0.12) release

Docs Site

Documentation is now supported and hosted directly in our website, at run.house/docs. Easily access documentation for any of or current and past releases.

Other

• Environment caching, skip env subpackage installations if existing environment is already detected
• ssh proxy tunnel support for BYO clusters (#85)
• troubleshooting and manual setup instructions for commonly encountered issues
• add runhouse start command

BC-Breaking

• rename runhouse restart_server command to runhouse restart

v0.0.10

What's New

Support for BYO clusters requiring a password

• To create a Runhouse cluster instance for a cluster that requires password authentication:
  rh.cluster("cluster-name", host=["hostname or ips"], ssh_creds={'ssh_user': '...', 'password':'*****'},

Funhouse/Tutorials Updates

• Update funhouse organization structure
• Deprecate tutorials repo in favor of tutorial walkthroughs in docsite and funhouse for standalone scripts

Sentry integration for Runhouse error reports

v0.0.9

Patch release to upgrade skypilot version to v0.3.3, which resolves a critical dependency fix for PyYAML following the Cython 3 release. On Runhouse side, fix a bug for handling git function environment requirements.

v0.0.8

What's New

Bugfixes

• FastAPI recently released 0.100.0, which upgrades to Pydantic v2. This introduced breakage in Runhouse and for now we've pinned to FastAPI<=0.99.0.
• Autostop for OnDemandClusters broke following the release of SkyPilot 0.3.0, as SkyPilot began to use their own Ray server on a separate port. When we started the Runhouse server, we were inadvertently killing the SkyPilot server, which caused the cluster status to show as in the INIT state indefinitely and suspended autostop.
• The recently introduced Env.working_dir caused the working directory to be synced to the cluster extraneously, which is now fixed.
• Ray does not work with PyOpenSSL<21.1.0, which was causing pesky breakage in some multiprocessing scenarios. We've pinned pyOpenSSL>=21.1.0.
• Improve performance by removing several RNS lookups.

v0.0.7

What's New

Dashboard & Login

• New resource dashboard and login link

Env

• Support passing in env_vars and custom working_dir to Env resource (#75)
• Better auto torch version handling for requirements.txt files
• Support "requirements.txt" auto file detection

Docs and Tutorials

• Updated README, check it out! (#73)
• New transformers training tutorial
• New accessibility API tutorial
• Example code snippets for resource methods (#74)

BC-Breaking

Factory Functions (#67)

• Remove load parameter, instead will automatically try to load from name argument if that is the only argument provided
• Default dryrun=False

Deprecations

• Use ondemand_cluster instead of cluster for On-Demand cloud clusters